Почему наследование не может быть основой ОС?

[Илья Ермаков]

Ничего не понял. Не вижу разницы. Хоть у меня интерфейс и его реализация, хоть два класса в иерархии наследования реализации, один фиг для операционной системы A у меня будет исходник Xa, для операционной системы B у меня будет Xb, и все. Выбор реализации для сборки ложится на плечи системы сборки. Тот кто отнаследовался от X, тому глубоко будет пофиг что там внизу на самом деле - Xa, или Xb.

А у меня вот никогда не бывает двух реализаций одного модуля. Они обособляются в модули (читай "классы") со своими именами. Например, X_win и X_lin. Более того, они могут присутствовать в готовом комплекте одновременно. Этим я могу достигать занятного эффекта, когда большинство откомпилированных модулей не имеют ОС-зависимого кода и потому бинарно совместимы и с Win, и c Lin; присутствуют не перекрывающиеся по именам модули ОС-зависимых реализаций - и два пускача, для каждой ОС. Т.е. бинарно совместимый с двумя ОС комплект.

Если в системе где-то затешется класс X, для которого должны быть две версии исходника - а нужную выбирает система сборки, то такое невозможно.

[adva]

А вот если "A" - это интерфейс, то все, алес. Узнать что именно произойдет при вызове obj->DoSomething() не представляется возможным - там может быть абсолютно что угодно. В общем случае единственным способом узнать это - использовать пошаговый отладчик. В точности то же самое, что и в случае goto (и то же что и при использовании процедурных типов).

Илья, мне кажется это достаточно справедливо. Просто Вы работаете в основном на ББ, где все знаете от и до, причем на своих проектах. А если бы пришлось разбираться с аналогичным чужим кодом и причем не в блекбокс?

[valexey_u]

Ничего не понял. Не вижу разницы. Хоть у меня интерфейс и его реализация, хоть два класса в иерархии наследования реализации, один фиг для операционной системы A у меня будет исходник Xa, для операционной системы B у меня будет Xb, и все. Выбор реализации для сборки ложится на плечи системы сборки. Тот кто отнаследовался от X, тому глубоко будет пофиг что там внизу на самом деле - Xa, или Xb.

А у меня вот никогда не бывает двух реализаций одного модуля. Они обособляются в модули (читай "классы") со своими именами. Например, X_win и X_lin. Более того, они могут присутствовать в готовом комплекте одновременно. Этим я могу достигать занятного эффекта, когда большинство откомпилированных модулей не имеют ОС-зависимого кода и потому бинарно совместимы и с Win, и c Lin; присутствуют не перекрывающиеся по именам модули ОС-зависимых реализаций - и два пускача, для каждой ОС. Т.е. бинарно совместимый с двумя ОС комплект.

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

А если нужна динамичность (сейчас у нас X такой, а через 5 минут он у нас уже другой), то ты же понимаешь, что наследование реализации нам никак принципиально не помешает во время работы программы поменять у данного класса A базовый класс X?

[vlad]

Наследование реализации не зависит от этих... эпитетов... Это уровни защиты кода/ограничения видимости, не более того...

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

[vlad]

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

Т.е., с тем же успехом можно писать public - но public для потрохов писать не кошерно (во всех книжках про это написано). Поэтому пишем protected - и инкапсуляция типа есть и думать лишний раз не надо.

[vlad]

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

С friend'ами, кстати, тоже самое. Инструмент точечного применения, который любят использовать не по делу. Лучше чем protected, потому что все левые сущности явно прописаны.

[Илья Ермаков]

А если нужна динамичность (сейчас у нас X такой, а через 5 минут он у нас уже другой), то ты же понимаешь, что наследование реализации нам никак принципиально не помешает во время работы программы поменять у данного класса A базовый класс X?

Хм, а это как?? Метамеханизмы всяких .NET-ов?

[Илья Ермаков]

2 Alexus:

Про сокрытую реализацию Вы недопоняли.

Имеется в виду, что доступен для всех только абстрактный класс, допустим, AbstractButton. Любой конкретный Button недоступен в принципе. А могут быть только созданы его экземпляры через фабрику (функцию или фабричный объект). А работать с ним будут как с AbstractButton.

[valexey_u]

А если нужна динамичность (сейчас у нас X такой, а через 5 минут он у нас уже другой), то ты же понимаешь, что наследование реализации нам никак принципиально не помешает во время работы программы поменять у данного класса A базовый класс X?

Хм, а это как?? Метамеханизмы всяких .NET-ов?

Да нет, никаких метамеханизмов дотнетов, обычный Smalltalk или даже возможно Objective-C.

Ну подумай сам, что тут нас может остановить? (если не зацикливаться на какой-то конкретной реализации наследования). Для подобного даже виртуальный машина не нужна.

Если мы желаем абсолютно все делать через ООП, то нам нужна полноценный его реализация, без искусственных ограничений. (к счастью в С++ никто никогда не предлагал делать все исключительно через ООП, в нем достаточно других, ортогональных методов)

[alexus]

2 Alexus:

Про сокрытую реализацию Вы недопоняли.

Имеется в виду, что доступен для всех только абстрактный класс, допустим, AbstractButton. Любой конкретный Button недоступен в принципе. А могут быть только созданы его экземпляры через фабрику (функцию или фабричный объект). А работать с ним будут как с AbstractButton.

Илья Евгеньевич, мне кажется, что это Вы недопоняли... Надо либо перестать использовать общеупотребимые термины, либо использовать их по назначению. А вкладывать своё понимание... без предупреждения читателей... не доблесть.

[adva]

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

А в итоге просветите, пжста, Ваше отношение к "наследованию реализации" (или как это теперь правильно назвать?) совпадает с отношением к ним Ильи? Если нет, то я так и не понял, каково Ваше отношение к "наследованию реализации" в применении к проектированию программных систем, как именно оно может/должно использоваться.

[alexus]

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

А в итоге просветите, пжста, Ваше отношение к "наследованию реализации" (или как это теперь правильно назвать?) совпадает с отношением к ним Ильи? Если нет, то я так и не понял, каково Ваше отношение к "наследованию реализации" в применении к проектированию программных систем, как именно оно может/должно использоваться.

Наследование реализации, или просто наследование¹ является очень эффективной парадигмой при разработке систем. Как это применяется я показывал на примере проекта СУБД. Для разработки программ наследование необходимо в значительно меньшей степени.
То, что Илья Евгеньевич называет "наследованием" реализации... практической пользы не даёт по сравнению с тем, что в ООП называют наследованием. К сожалению, Н. Вирт видимо так и не понял возможностей ОО-концепции, что сказалось и на Обероне, и... на его адептах.

---
¹ "Наследование" интерфейсов опрометчиво назвали "наследованием", поскольку порождают этим путаницу.

[Valery Solovey]

Так в том-то и дело, что настоящее наследование к "наследованию реализации", отношения практически не имеет. И Илья с Вами согласен, что оно практической пользы не даёт.

[valexey_u]

Так в том-то и дело, что настоящее наследование к "наследованию реализации", отношения практически не имеет. И Илья с Вами согласен, что оно практической пользы не даёт.

Господа, вы меня совсем запутали.

Итак, раскладываем по полочкам:
1) alexus утверждает что наследование у интерфейсов это не наследование.
2) Valery Solovey утверждает что Илья согласен с alexus'ом (и видимо сам Valery Solovey тоже согласен) и что настоящее наследование к наследованию реализации не имеет отношения.

Пардон, а что тогда остается? Интерфейсов наследование отпадает (1), реализации наследование тоже отпадает (2). Ы?

[Илья Ермаков]

То, что Илья Евгеньевич называет "наследованием" реализации... практической пользы не даёт по сравнению с тем, что в ООП называют наследованием. К сожалению, Н. Вирт видимо так и не понял возможностей ОО-концепции, что сказалось и на Обероне, и... на его адептах.

А на чём ещё основаны "возможности ОО-концепции", как не в полиморфизме (возможности выразить отношения "род-вид" и потом обеспечить принцип Барбары Лисков:, если A` является разновидностью А, использовать его всюду, где и А) и в виртуализации (позднем связывании вызова)?

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