Нет, не согласен. ---
Существует и такое определение моста, практически научно-крестьянское :
мост - это замена наследования агрегированием. Вообще.
---
Любой класс, который мы делаем - это некая абстракция. Срез реальности,
пропущенный через мозг программиста.
И если реализацию некой части (или всего) этой абстракции мы выделяем
в отдельную иерархию - это и есть мост.
Идеально - если если эта часть явным образом и совершенно
очевидно некая другая сущность.
Уже практический пример - он близок любому бедуину:
.. Мы подключаем дивайсы к компу поcредством RS485.
Каждому дивайсу в софте компа ставим в соответствие объект.
Имеется объект COM-порт. Но как мастерить иерархию дивайсов дальше ?
Порт один на всех, дивайсов много.
Просто невозможно применить наследование.
Вот тогда мы и делаем "мост".
Каждому объекту-дивайсу предусматриваем указатель на объект COM-порт.
Получился мост, и без всяких абстрактных классов.
Однако, если предполагаются разные реализации приёма/передачи пакетов,
тогда следует применить указатель на интерфейс.
Например, софт от FTDI даёт возможность использовать её внутренние функции,
похожие на функции COM-порта Виндус. Это уже 2 варианта. А если предполагается
появления дивайсов с тем же протоколом, но по UDP или TCP - вот уже 4 варианта.
Далее, мы реализуем разные логические уровни (абстракции) протокола
разными объектами. Может применить наследование ? Мне не нравицца.
Вдруг у нас (у меня точно) дивайсы разные (разнородные) - а протокол один.
Различие только в пользовательских функциях.
Опять мост. Объект пользовательских функций получает указатель
на реализацию общих (для всех дивайсов) функций протокола.
Так объективно легче менять общую реализацию протокола и менять её.
А также легко и просто мастерить новые объекты пользовательских
функций для новых разработанных дивайсов.
Tyмблep (08.07.2024 15:44, просмотров: 73) ответил RxTx на Неправильное понимание паттерна "мост" и его назначения. Сразу пишу
что неправильно, это тонкий вопрос в дизайне и архитектуре. Смысл
паттерна "мост" не в том, чтобы соорудить некую общую абстракцию и
наделять её смысловой реализацией, разделив их. Смысл только в том
чтобы технически разделить интерфейс и технически позволить
подменять актуальную реализацию. И абстракция-интерфейс и
реализация как правило чётко определены (т.е. вообще-то глобально
мы ЗНАЕМ, однако так