или

Вот если объект класса B может всегда и везде выступать как объект класса A, если контракты B полностью соответствуют контрактам A (в случае методов можно ослаблять предусловия и усиливать постусловия), тогда и применимо наследование

Есть еще более классическая фигня - лопата копает яму, или яма копается лопатой?

Принцип-то простой, но куда его прикладывать на практике я так до конца и не вкурил

Барбара Лисков предложила довольно простой принцип.

1) Наследование используется, если имеем отношение "является"

А-я-яй! Врешь и не краснеешь На первой же странице:

То, что квадрат является частным случаем прямоугольника никоим образом не означает, что должна быть иерархия классов и наследование. Нам достаточно интерфейса Фигура и класса Прямоугольник, который его реализует. Нет причин не сделать его иммутабельным, без сеттеров, с конструктором на два аргумента. Для частного случая — квадрата — может быть либо конструктор с одним аргументом, либо, что лучше, как рекомендует Блох, статический фабричный метод с названием.

а в данный момент вообще плотно обмазалась Elixir-ом.

Если верить applegame'у, то в D - не придется копипастить все руками, язык поддерживает это из каробки. Соответственно в таком языке можно вообще уходить смело от наследования.

Это ради бога, вот только есть верить hh.ru, то этот D нахрен никому не нужен, а значит нет смыла тратить на него свое время

Небось это контора applegame и искала спецов

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

Это ради бога, вот только есть верить hh.ru, то этот D нахрен никому не нужен, а значит нет смыла тратить на него свое время

Если верить applegame'у, то в D - не придется копипастить все руками, язык поддерживает это из каробки. Соответственно в таком языке можно вообще уходить смело от наследования.

или просто сделать проперти, которая возвращает интерфейс агрегата.

Другое дело, что все это логично было добавлять агрегацией, а не наследованием

Может и проще, но для этого надо все переписать. Сейчас сделано в лоб - пришел евент -> добавили эвент в игру -> проверили нарушаются ли правила (их штук 10), если нарушаются, то создали соответствующий эвент -> отправили все (начальные и созданные) на отправку в подсистемы (сохранение в БД, отправка Textoverlay, сообщение о нарушениях итд). Т.е. наверное это ближе к наблюдателю, но переделывать существующий код никто не даст.

Может быть проще какой нибудь Visitor прикрутить или Наблюдатель там?

Ну вот видишь - вот и вылезла проблема. Рефакторингу не подлежит, т.к. вот такое наследование в него заложено. А была бы агрегация, то отрефакторилось бы легко.

Ну речь зашла о том, что наследование классов - это всегда плохо. Лучше ее избегать всегда и везде, где это возможно. И только если уж совсем приспичит, то можно оставить, и то с нацелом на то, чтоб потом переписать.

По поводу префиксов - необязательно так делать. Я думаю так делают в основном С++сники,

Пересмотреть дизайн - это написать все с нуля Тут коду больше 10 лет и сейчас сделан один класс, который отвечает за все. Недостатком такой структуры является то, что Textoverlay, AlarmMessage и DatabaseDto живут "вне" эвента в результате для обработки всего этого добра пишется куча ненужного кода.

Я не знаю всей специфики твоей задачи, но обычно всякие ивенты решаются с помощью шаблона Посетитель(Visitor) или Наблюдатель(Observer). Возможно тебе нужно пересмотреть дизайн. Слишком много у тебя наследования. ИМХО.

Тебя не смущает, что книга 1994-го года, а на дворе 2019-й? И что это не Конституция РФ и тем более не учебник по алгебре, например?
https://www.michaelsafyan.com/tech/design/patterns/singleton

Обычно это ToggleButton, который к чекбоксам никакого отношения не имеет, кроме как обеспечения такой же смысловой нагрузки: On/Off (Checked/Unchecked, и т.п.) — представления булевого свойства. Ты стиль наследуешь или поведение? Ну да, в этих ваших фреймворках часто представление и семантика слиты в один класс. Каша, да и только. Потом наследуете мух от котлет и наоборот.

«Дополнительные»? Лол, это и есть вся его смысловая нагрузка, определяющая суть чекбокса как элемента интерфейса.

При чём тут язык программирования? Мы о UI фреймворках/тулкитах говорим. HTML+CSS+JS — это UI-тулкит.

Interface Segregation Principle.

Flying может быть не только Vehicle. Ты внимательней прочитай.

А маленькие буквы в именах полей в C# тебя не бесят?

Нахера вы захламляете имена идиотскими префиксами? У классов префикс C пишете?

А у абстарктных классов — AC? А если публичный, нужно P добавлять? А S к sealed?

С глобальной переменной это сделать проще.

Незнаю, вот у меня перед глазами лежит книга "Приемы Объектно-Ориентированного проектирования. Паттерны проектирования" за авторством: Э.Гамма, Р.Хелм, Р.Джонсон, Д.Влиссидес.
Синглтон описывается на странице 130. Обозначен как паттерн проектирования

Между прочим, в некоторых фреймворках, чекбоксу можно сделать стиль PressedButton, т.е. меняется только отрисовка - вжатая/отжатая кнопка, либо галочка - есть/нет.

ну разве что вводятся дополнительные свойства - Checked/Unchecked

то что такое check - остается только догадываться. Никогда не встречал такого класса

Даже в HTML он идет как checkbox

Да причем тут HTML то я никак не пойму? Ты сравниваешь разметку с языком программирования.

Что такое ISP?

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

А меня бесят маленькие буквы в методах в Java. Придумали какую то хрень, не пойми зачем, и приходится потом с этим извращаться.

Нечаяно можно и метод в базовом классе поменять и поломать всё к чертям.

Синглтон — антипаттерн уже давно.

Вот и по рукам тебе за такой класс надавать. CheckBox — это не Button.

CheckBox = Pane { check ; label }

Какие те же? Зачем CheckBox'у методы Button'а? Ты про click/keypress/etc? Так это не методы Button'а. Ещё раз посмотри на HTML: на любой элемент можно повесить onclick-обработчик, например.

В том что нет ISP.

Почувствуй разницу.

Как же раздражает ииотская шарповая нотация

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

Если сильная связь подразумевается, как в лице гуёвых иерархий, например, когда кнопка она же окно, то наследование не привнесёт дополнительного дисбаланса в архитектуру. Переделывай базовый класс окна на здоровье, кнопки автоматом подхватят все модификации, и разве не это ожидается в итоге?

Глобальную переменную легко переписать нечаяно в каком то другом месте.

Хотя и их используют там, где они оправданы, синглтон никто не отменял

вот есть у меня класс Checkbox : public Button, у класса checkbox я реализовал функцию отрисовки, все. Теперь у меня есть checkbox, который имеет все те же методы что и кнопка, но выглядит по другому.

Как это будет выглядеть с агрегированием?

Чтоб у чекбокса были все те же методы?

Я бы с удовольствием это выдумал, но увы, приходится цитировать.

В чем заключается говнокод?

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

Ну речь зашла о том, что наследование классов - это всегда плохо.

Решения при помощи агрегации я тут не вижу.

У всех транспортных средств есть только одно общее поведение "перемещаться". Те, которые с двигателем - "заправляться", "расходовать топливо". А все остальное, например - способ перемещения, тип топлива, я бы отнес к свойствам уже классов. Я не прав?

Интерфейсы определяют поведение. Не пойму зачем в приведенной иерархии связывать "колесо" и "мотор" или "дизель" и "мотор"? У всех транспортных средств есть только одно общее поведение "перемещаться". Те, которые с двигателем - "заправляться", "расходовать топливо". А все остальное, например - способ перемещения, тип топлива, я бы отнес к свойствам уже классов. Я не прав?

ЗЫ: Да и то, не все, что с двигателем - заправляются, например трамвай.

При проектировании отношений между классами надо учитывать некоторые общие рекомендации. В частности, вместо наследования следует предпочитать композицию. При наследовании весь функционал класса-наследника жестко определен на этапе компиляции. И во время выполнения программы мы не можем его динамически переопределить. А класс-наследник не всегда может переопределить код, который определен в родительском классе. Композиция же позволяет динамически определять поведение объекта во время выполнения, и поэтому является более гибкой.

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

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

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

Зачем обызательно заменять агрегацию наследованием или наоборот? Для каждой задачи свое решение.

По твоему этот пример можно переписать как:

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

Странно что ты Fester читал, читал и даже примера не написал. А я уверен что ты бы написал в рабочем проекте вот такую иерархию:

Да и тут бы ты ее написал скорее всего - потому что это логично.

А речь идет о том, что так делать нельзя, потому что это приводит к ошибкам.