Существует ли способ определить является ли класс/инстанция наследником от другого(заданного) класса?

К примеру, в Delphi используется оператор is:
procedure TForm1.FormShow(Sender: TObject);
begin
if sender is TForm then
{ ... }
;
end;

А зачем?
Если необходимо вызвать метод, который наследуется от предка, достаточно сделать CASTING.


Рекомендую изучить курс BC401.

Для использования [s]полиморфного[/s] специфического поведения наследников.

Подклассы одного родителя могут иметь свои _дополнительные_ методы.
Чтобы их(дополнительные методы) вызвать нужно уточнить принадлежность переданной инстанции (как ссылку на общий класс) к конкретному классу.

2 gentle: Как мне кажется, подобный подход как раз противоречит полиморфному принципу и принципам ООП об инкапсуляции. Получается, что тот класс\метод\софт в котором вы хотите это делать должен слишком много знать о других классах.

2 Кодер: Обсуждение принципов ООП можно оформить в отдельную тему.

Хотелось бы просто получить ответ на конкретный вопрос, указанный в данной теме.

Ответ я уже дал.
По поводу полиморфизма - это как раз возможность вызывать методы наследников, интерфейс которых определен в родителе.

Какого-то конкретного оператора нет. Можно наваять что-то свое, используя, например, методы класса CL_ABAP_CLASSDESCR.Хотя Вы, судя по всему, склонны сделать по-своему , присоединюсь к критике Кодера и Удава. Это [не совсем/совсем не] полиморфизм. И при таком подходе у Вас появится сильная связанность (coupling) классов. Имхо, лучше использовать паттерн метод шаблона (template method).

Вот тут автор размышляет над 'IS INSTANCE OF', и заодно у него там есть пример как это выглядит на абапе

Благодарю за полезные советы и ссылки!

А по моему это вполне стандартная операция в ООП. Тот же класс CL_ABAP_TYPEDESCR имеет такую структуру наследников:



В документации пример:



Получается мы приводим ссылку к более специфическому классу чтобы получить более специфическую информацию. (cl_abap_typedescr=>describe_by_name( 'C01' ) возвращает объект типа CL_ABAP_TYPEDESCR)

2 AFH: Ага, все правильно. В приведенном Вами коде, клиентское приложение твердо знает, что на вход cl_abap_typedescr подали именно класс, а не гадает на ромашке "а не класс ли это?". И уж тем более не гадает "а не класс ли это. у которого в предках вот такой вот класс-родитель?"

2 Кодер
Я это написал к тому что есть мнение:


С которым я немножко не согласен Хотя можт быть я неправильно уловил суть обсуждения.

2 AFH.
Приведенный Вами пример немножко отличается от того, что хотел реализовать (уже реализовал? ) топикстартер.
В примере метод класса каким-то образом (для внешней программы неважно каким) определяет, ссылку на объект какого конкретного класса нужно вернуть. Внешняя программа знает, что она должна получить, и преобразовывает ссылку на объект родительского класса к ссылке на объект нужного дочернего. И только потом уже использует специфические методы. Т.е. вызовом специфических методов занимается внешний код, который знает, с чем конкретно он работает. А не "внутренний" код, который просто создает нужный объект и возвращает ссылку на него.
Топикстартер хотел реализовать логику, когда вызов специфических методов осуществляется "внутри". Т.е. "внутрь" приходит ссылка на хз-что, и "внутренний" код самостоятельно разбирается, что это такое, и какие методы он может вызывать.
Может, это и не нарушение принципов ООП (фактически, при такой логике полиморфизм просто не используется или используется не везде), но, имхо, неудачный подход: при любых изменениях в иерархии, к которой принадлежит TForm1, придется анализировать и, возможно, править код FormShow. А если таких FormShow еще и несколько, при малейшем изменении иерархии появляется риск получить полную гамму малоприятных сексуальных удовольствий.

Итак, подводя итоги обсуждения, для реализации поставленной задачи был получен нижеследующий код(в первом приближении):

Кажется, работает . Только не учитывает реализацию (implementation) интерфейсов.