Ты вроде подменяешь понятия (относительно того, кто и что должен обосновать)
Для чего нужен мост описано в гоф - отделяет абстракцию от реализации. Это и нужно, отделить интерфейс, который может быть общим, от реализации, которая для кого-то будет общая, для кого-то нет. Тут тебе и общий интерфейс, и нет дублирования кода. Я думаю, ты просто не грокнул паттерн, и потому отвергаешь его даже без обсуждения
А ещё ты потратил уже много времени и букв, но по сути своих претензий ничего пока не сказал ;)
По поводу твоего замечания про наследование в целом - я до ноды писал на плюсах (в основном, но не только), и к наследованию априори отношусь с подозрением, потому что там слишком много тонкостей: виртуальное наследование, или ромб при множественном наследовании, переопределение (и, следовательно, сокрытие) невиртуальных методов, и прочая муть. Когда фанаты выстраивают свои конструкции, висящие на соплях, и всё это ненадёжное сооружение начинает разрастаться и приводит к трудно определяемым ошибкам в лучшем случае на этапе компиляции, они сами на собственном опыте постигают описанное ещё мейерсом простое правило: предпочитаете композицию наследованию. Рекомендую почитать, скорее всего это в первой его книге было, где фигурирует число 55
В других языках типа жавы или Шарпа попробовали решить проблемы наследования по своему, но не сказать, что им это хорошо удалось
А ещё можно смотреть на наследование не только как на способ избежать дублирования кода, а как на способ обеспечить полиморфизм (поэтому фраза про три столпа ООП несколько искуственна, потому что дублирует сущности). Способов избежать дублирования кода масса, и они есть даже в кондовом процедурном программировании на каком-нибудь бейсике. Равно как и способов обеспечить полиморфизм. Так что и с этой точки зрения не стоит зацикливаться на наследовании:
- его можно заменить
- оно не решает ни одной проблемы, которую нельзя решить без него
- оно привносит проблемы
Всё, хватит аргументации?
Понятно, что паттерны придумали не дураки и ни от хорошей жизни, связанной с наследованием. Но в книжках или у мамкиных блогеров хеловордные примеры с удобными для паттернов предметными областями. Паттерн наблюдатель? Отлично, сделаем пример с наблюдением за погодой. И в таком духе... А в жизни приваливает предметная область с такими кейсами, которые тебе в жизни не снились, и начинается натягивание совы на глобус. Тут простая школьная геометрия, а не кровавый интерпрайс, а уже началась смехопанорама с созданием объектов, типа вычислитель площади круга отдельно от самого круга... При том, что опровергнуть простоту наследования от неправильного многоугольника, который по сути является математическим движком для наследников, где остается сделать какую-то мелоч, вроде контроля за количества вершин, переданных в конструктор, ты толком не можешь. Попросил тебя разложить пататерн по его состовляющим из Википедии в контексте фигур, ты написал кучу страшных слов вместо примера. Если не знаешь всех предметных областей, где метода может быть действительно целесообразно, не проник в мировой абсолют, так и нефиг говорить, что от наследования нужно избавляться в пользу какого-о там бла-бла-бла паттерна, если не подходит, то сорян.
