Как отличить абстрактный класс от "реального"

[Cellard]

Возникла нетривиальная задача.

Допустим у нас есть абстрактный класс. Назовем его GroundZero.
Он много раз расширен как абстрактными, так и "реальными" классами.

Задача: получить всех "реальных" потомков этого класса и инстанциировать их.

Используя функции get_declared_classes() и get_parent_class() я без труда нахожу всех потомков GroundZero. Но как исключить из них абстрактные классы?

 

[Духовность™]

вы не должны этого хотеть

 

[Dovg]

Предок в общем случае ничего не должен знать о потомках.

 

[Cellard]

Предок в общем случае ничего не должен знать о потомках.

У меня это условие нигде и не нарушается.

Переформулирую задачу:

Даны имена двух классов — А и Б. Известно, что один из них абстрактный. Вопрос: какой?

 

[Духовность™]

Открой код и посмотри, как абстрактный, а какой нет.

 

[Cellard]

Открой код и посмотри, как абстрактный, а какой нет.

Вы глупости говорите. Очевидно же, что эта информация нужна не мне лично, а программе во время выполнения.

 

[Alien85]

напишите, в каком случае может понадобиться такая информация?

 

[A1x]

Cellard
Reflection?

 

[Cellard]

напишите, в каком случае может понадобиться такая информация?

Попробую...

Есть некоторая абстрактная прослойка, в которой реализованы все рутинные операции. Над этой прослойкой существует другая, тоже абстрактная, в которой реализована модель безопасности.
Часть классов расширяет базовую абстракцию; а те классы, для которых требуется проверять права доступа, реализуют модель безопасности.

Для того, чтобы предоставить администратору возможность в удобном виде настраивать права доступа, необходимо иметь статистику по проекту — какие классы реализуют модель безопасности.
Сделать это можно вручную — перечислив все такие классы, или автоматически — для чего мне и понадобилось это извращение.

 

[Cellard]

Cellard
Reflection?

Спасибо! То, что надо.

 

[Духовность™]

Вы глупости говорите. Очевидно же, что эта информация нужна не мне лично, а программе во время выполнения.

Глупости - это делать то, что Вы делаете.

 

[Cellard]

Глупости - это делать то, что Вы делаете.

Рад бы с вами согласиться, но в отсутствие аргументов — не могу. Попробуете объяснить?

 

[jonjonson]

Cellard, абстрактный класс создаётся не для реализации, а для дисциплины реализующих.

 

[Cellard]

Cellard, абстрактный класс создаётся не для реализации, а для дисциплины реализующих.

Как это понимать? Надеюсь, не как запрет на реализацию методов в абстрактном классе?

 

[jonjonson]

Cellard, запрещать вам никто не станет. Но вот в документации чётко сказано

Methods defined as abstract simply declare the method's signature they cannot define the implementation.

 

[Adelf]

jonjonson
Чем тогда абстрактный класс от интерфейса отличается?

Глупости - это делать то, что Вы делаете.

Никогда статистическую инфу по проекту не собирал? Вникнись в суть того что хочет ТС. Один раз собрать инфы и все.
А писать "вы" с большой буквы - моветон.

 

[Cellard]

В этом предложении нет ни слова об абстрактном классе, в нем речь об абстрактных методах. Причем это предложение не дискуссионное, а аксиоматичное. В нем постулируется, что абстрактный метод не может иметь тела. Это настолько очевидные азы, что я теперь тем более не понимаю, что вы имели в виду. Какое все это имеет отношение к моему может быть и странному, но в целом невинному желанию создать сервисную функцию, которая соберет статистику о классах, использованных в проекте?

 

[jonjonson]

Cellard, а через что имплементируется класс? Не через методы? Вот момент имплементации говорит, что абстракция закончилась и пора вешать в граммах.
Adelf, интерфесы это жосче. Мы обязаны сделать то и то. А абстрактный - мы собираемся сделать то и то. И даже вот основу не изменную имплементируем. А остальное потом имплементируем.

 

[jonjonson]

Adelf, и кстати да. У меня то же есть сомнения некоторые. Но их уже евангелистам.

 

[Adelf]

jonjonson
не нужны тут евангелисты. Не надо абстрактные классы использовать как интерфейсы. В них может быть логики гораздо больше, чем в потомках. И ничего плохого в этом нет. Глянь хотя бы Kohana, ZF.