Потому что твой коммент примерно в таком прямоугольнике и находится, только слегка трасформированном. @murzilka17 , так будет Мост или расходимся?

Я не вижу предмета для обсуждения
Ты пишешь, что он не подходит, но не описываешь причин почему
Не нравится мост - пусть будет не мост, а композиция вместо наследования
Опять не нравится? Ну тогда сорян

Если ты вместо моста предложишь патерн Дыня, я должен описать причины почему он не подходит? Ну даешь))) Ладно, понял тебя, давай.

Странно, не слышал о таком паттерне, а название запоминающееся

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

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

Кто что думает про nest?

Ты вроде подменяешь понятия (относительно того, кто и что должен обосновать)

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

А ещё ты потратил уже много времени и букв, но по сути своих претензий ничего пока не сказал ;)

По поводу твоего замечания про наследование в целом - я до ноды писал на плюсах (в основном, но не только), и к наследованию априори отношусь с подозрением, потому что там слишком много тонкостей: виртуальное наследование, или ромб при множественном наследовании, переопределение (и, следовательно, сокрытие) невиртуальных методов, и прочая муть. Когда фанаты выстраивают свои конструкции, висящие на соплях, и всё это ненадёжное сооружение начинает разрастаться и приводит к трудно определяемым ошибкам в лучшем случае на этапе компиляции, они сами на собственном опыте постигают описанное ещё мейерсом простое правило: предпочитаете композицию наследованию. Рекомендую почитать, скорее всего это в первой его книге было, где фигурирует число 55
В других языках типа жавы или Шарпа попробовали решить проблемы наследования по своему, но не сказать, что им это хорошо удалось

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

Всё, хватит аргументации?

Та зачем нам эти тексты читать. Ты пример Моста с фигурами приведи )))

Та да @ellenaua подкинула на вентилятор и ушла 😂

Божечки, для отделения абстракции от реализации используются интерфейсы

Они не везде есть

Поджигать так поджигать...
ПХП:)

Вот в js их нет

товарищ архитектор их даже в жс имплементить умудряется)
правда не все программисты как товарищ архиектор

Тут взрослые такие вещи обсуждают а ты....

Да понятно, что в языках с утиной типизацией реализовать интерфейс просто
Но в самом языке такого понятия, или конструкции для него, нет

Что уж говорить о древнем зле типа тех же плюсов. Потому несколько удивителен возглас про божечку

ммм, он хто затійник.

Во, вспомнил
Ещё одна проблема, которую позволяет решить мост - динамическая смена реализации. Пользователь расширил квадрат неравномерно и квадрат перестал быть квадратом? Никаких проблем, меняем ему реализацию, которая вычисляет площадь, и не надо пересоздавать сам объект
С застывшим в граните наследованием так не выйдет

Метархия, это не только лекции, код и мемы, а еще и культура, тут у нас, куда не плюнь, или культура или духовность: @CulturaCulturans