История изменений

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

нет там никакого «наследования реализации» по дефолту. наследование это в чистом виде отношение - «is a» композиция - отношение «consists of»

и второе никак не заменяет первое. потому что автомобиль есть «средство передвижения», а «consists of» - мотор и 4 колеса.

если вы инкапсулируете «средство передвижения» в автомобиль - у вас просто неверно устроенный класс. ибо автомобиль не может состоять из «средства передвижения».

Наследование без реализации — это и есть использование инструмента не по назначению

аналогично вы не можете отнаследовать автомобиль от мотора и 4 колес. и именно такую дурь обычно и эксплуатируют в своих аргументах критики «наследования».

у вас нет способа коректно отразить is_a, усли у вас нет наследования хоть тушкой, хоть чучелом.

если вам в разработке такое отношение is_a - даром не надо, то пробуйте без воды и костылей спроктировать библиотеку для гуя, где вся ветвистая иерархия растет от базового класса window или типа того. вам по-любому придется делать квазинаследование через задний проход, ну или виде «наследования» интерфейсов.

Наследование без реализации — это и есть использование инструмента не по назначению

в кондовом ооп можно наследовать хоть с реализацией, хоть без.

class Base {
public:
  void fun1();
  Base();
}

или так

class HiddenBase;
class Base {
  HiddenBase* _hidden;
public:
  void fun1();
  Base();
}

если у вас есть общие свойства, то они должны быть где-то реализованы.

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

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

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

нет там никакого «наследования реализации» по дефолту. наследование это в чистом виде отношение - «is a» композиция - отношение «consists of»

и второе никак не заменяет первое. потому что автомобиль есть «средство передвижения», а «consists of» - мотор и 4 колеса.

если вы инкапсулируете «средство передвижения» в автомобиль - у вас просто неверно устроенный класс. ибо автомобиль не может состоять из «средства передвижения».

Наследование без реализации — это и есть использование инструмента не по назначению

аналогично вы не можете отнаследовать автомобиль от мотора и 4 колес. и именно такую дурь обычно и эксплуатируют в своих аргументах критики «наследования».

у вас нет способа коректно отразить is_a, усли у вас нет наследования хоть тушкой, хоть чучелом.

если вам в разработке такое отношение is_a - даром не надо, то пробуйте без воды и костылей спроктировать библиотеку для гуя, где вся ветвистая иерархия растет от базового класса window или типа того. вам по-любому придется делать квазинаследование через задний проход, ну или виде «наследования» интерфейсов.

Наследование без реализации — это и есть использование инструмента не по назначению

в кондовом ооп можно наследовать хоть с реализацией, хоть без.

class Base { public: void fun1(); Base(); }

или так

class HiddenBase; class Base { HiddenBase* _hidden; public: void fun1(); Base(); }

если у вас есть общие свойства, то они должны быть где-то реализованы.

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

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