[Sauris 0]

"всяческое там наследование и соотв. расходы" - наследование не приводит к доп. расходам в общем случае (если нет вирт. методов).

Ага, а RTTI, dynamic_cast и прочая хрень с идентификацией типов? Она при помощи божьего промысла делается?

[dxp 65]

Ага, а RTTI, dynamic_cast и прочая хрень с идентификацией типов? Она при помощи божьего промысла делается?

Какая связь между всяческим наследованием и RTTI?

[Sauris 0]

Какая связь между всяческим наследованием и RTTI?

 

Один из основных (в смысле реально полезных в жизни) инструментов работы с наследованием - dynamic_cast, а он использует RTTI, как минимум для того, чтобы возбудить исключение bad_cast, если пытаешься не то к не тому привести.

Изменено 2 марта, 2012 пользователем SAURIS GmbH

[dxp 65]

Один из основных (в смысле реально полезных в жизни) инструментов работы с наследованием - dynamic_cast, а он использует RTTI, как минимум для того, чтобы возбудить исключение bad_cast, если пытаешься не то к не тому привести.

RTTI живёт само по себе и с наследованием пересекается весьма опосредовано. Если посмотреть, сколько динамик_кастов делается по отношению к числу случаев использования наследования, то это будет исчезающе малая величина. Уж никак на основной инструмент для работы с наследованием это тянет.

 

RTTI нужно для определения соответствия типа объекта ожидаемому, чтобы корректно использовать потом объект.

 

Наследование же предназначено для организации повторного использования кода, когда можно быстро создать сложный объект, не переписывая кучу кода, где ещё и ошибок наделать.

[Sauris 0]

Уж никак на основной инструмент для работы с наследованием это тянет.

 

Для того, чтобы быть одним из основных, не надо быть одним из самых массовых. Достаточно чтобы он раз-два применялся в программе, но зато почти в кажной.

 

А для повторного использования кода наследование нафиг не нужно. Для этого еще в ассемблере "подпрограммы" придумали. Наследование реально нужно (даже я бы сказал только для) для обеспечения полиморфизма наглядным и интуитивно-понятным способом, только для того, чтобы можно было перегрузить метод.

Изменено 5 марта, 2012 пользователем SAURIS GmbH

[dxp 65]

Для того, чтобы быть одним из основных, не надо быть одним из самых массовых. Достаточно чтобы он раз-два применялся в программе, но зато почти в кажной.

Основной - как раз, тот, без которого никуда. Который является основой. RTTI - это вообще вспомогательная примочка. В embedded проектах никогда не использовал, т.к. очень много накладных тащит, и тот же функционал (проверка соответствия типа) прекрасно реализуется другим способом.

 

А для повторного использования кода наследование нафиг не нужно. Для этого еще в ассемблере "подпрограммы" придумали. Наследование реально нужно (даже я бы сказал только для) для обеспечения полиморфизма наглядным и интуитивно-понятным способом, только для того, чтобы можно было перегрузить метод.

Отличное объяснение. Только вот мне одна вещь не понятна. Вот у меня есть класс, нормальный, отлаженный. Мне надо точно такой же, но с перламутровыми пуговицами ещё одним членом-данным и парой функций-членов (функционал чуть расширился). Как мне достичь желаемого без наследования - оно ведь только для полиморфизма и RTTI - с помощью старинного изобретения из ассемблера - подпрограмм?

[Sauris 0]

Как мне достичь желаемого без наследования

 

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

 

Я вообще не использую ООП никогда, если нет жесткой необходимости в полиморфизме и перегрузке методов. То есть ООП - это крайний случай, если уж без него ну просто никак.

Изменено 6 марта, 2012 пользователем SAURIS GmbH

[jcxz 242]

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

А зачем делать коряво и неэстетично если можно элегантно и красиво и без доп. расходов?

Религия не позволяет?

[Sauris 0]

А зачем делать коряво и неэстетично если можно элегантно и красиво и без доп. расходов?

Религия не позволяет?

 

Красиво, элегантно и без доп. расходов - это на ассемблере. Первый этап некрасивости и неэлегантности решения - увеличение доп. расходов в пользу быстроты написания и эстетичности - это С. А следующее увеличение доп. расходов (а как следствие еще большая неэлегантность) в пользу сомнительного ускорения написания и еще большей "эстетичности" - это ООП с использованием С++. А так по идее можно и на джаве написать например, или на андроиде, и обозвать это самым верхом элегантности. Так что религия позволяет самое разное, в зависимотси от того, сколько времени есть на реализацию проекта, и сколько лишних ресурсов в системе.

 

И вообще тут была речь совсем не об этом, а о том, что наследование методов (без перегрузки, т.е. полиморфизма) это ненужный механизм, которому эквивалентно вынесение их за пределы класса. Однако так как наследование есть основа для перегрузки, то оно именно в этом смысле необходимо, так как без него полиморфизм (ради чего стоит применять ООП) становится неудобен в реализации и сложен. Ну и раз наследование один черт нужно, то почему бы и не использовать его для методов, которые перегружать не запланировано, но это эквивалентно обычной функции вне класса

Изменено 6 марта, 2012 пользователем SAURIS GmbH