caxapa.ru :: Нет, не согласен.

Tyмблep (08.07.2024 15:44, просмотров: 237) ответил RxTx на Неправильное понимание паттерна "мост" и его назначения. Сразу пишу что неправильно, это тонкий вопрос в дизайне и архитектуре. Смысл паттерна "мост" не в том, чтобы соорудить некую общую абстракцию и наделять её смысловой реализацией, разделив их. Смысл только в том чтобы технически разделить интерфейс и технически позволить подменять актуальную реализацию. И абстракция-интерфейс и реализация как правило чётко определены (т.е. вообще-то глобально мы ЗНАЕМ, однако так

Нет, не согласен.

---

Существует и такое определение моста, практически научно-крестьянское :

мост - это замена наследования агрегированием. Вообще.

---

Любой класс, который мы делаем - это некая абстракция. Срез реальности,

пропущенный через мозг программиста.

И если реализацию некой части (или всего) этой абстракции мы выделяем

в отдельную иерархию - это и есть мост.

Идеально - если если эта часть явным образом и совершенно

очевидно некая другая сущность.

Уже практический пример - он близок любому бедуину:

.. Мы подключаем дивайсы к компу поcредством RS485.

Каждому дивайсу в софте компа ставим в соответствие объект.

Имеется объект COM-порт. Но как мастерить иерархию дивайсов дальше ?

Порт один на всех, дивайсов много.

Просто невозможно применить наследование.

Вот тогда мы и делаем "мост".

Каждому объекту-дивайсу предусматриваем указатель на объект COM-порт.

Получился мост, и без всяких абстрактных классов.

Однако, если предполагаются разные реализации приёма/передачи пакетов,

тогда следует применить указатель на интерфейс.

Например, софт от FTDI даёт возможность использовать её внутренние функции,

похожие на функции COM-порта Виндус. Это уже 2 варианта. А если предполагается

появления дивайсов с тем же протоколом, но по UDP или TCP - вот уже 4 варианта.

Далее, мы реализуем разные логические уровни (абстракции) протокола

разными объектами. Может применить наследование ? Мне не нравицца.

Вдруг у нас (у меня точно) дивайсы разные (разнородные) - а протокол один.

Различие только в пользовательских функциях.

Опять мост. Объект пользовательских функций получает указатель

на реализацию общих (для всех дивайсов) функций протокола.

Так объективно легче менять общую реализацию протокола и менять её.

А также легко и просто мастерить новые объекты пользовательских

функций для новых разработанных дивайсов.

Ответить

- Наследование вообще применимо мало где. Потому что оно предполагает строгую иерархию без побочных эффектов. А это применимо только для полностью абстрактных вещей типа графики, оконной системы. Там где голимая математика в памяти можно строить иерархию классов. Как только появляются реальные физические объекты лучше убегать в сторону агрегирования указателей и т.п. - =AlexD=(08.07.2024 15:45)
  - Приехали. =:0 Tyмблep(539 знак., 08.07.2024 15:53)
    - Абстрактный класс - это костыль плюсиков, в которых изначально не было интерфейсов. Кстати, кто-то из великих плюсоводов писал что дружественные функции пользительнее для здоровья. - =AlexD=(08.07.2024 16:16)
      - "Это другое, понимать надо" (c) Tyмблep(557 знак., 15.07.2024 14:14)
        
        Я и не сравниваю. Я абисняю что согласно последней моде наследоваться - харам (за исключение абстрактных костылей типа интерфейсов). Самый простой путь получить доступ к внутренностям - унаследоваться, что 98% плюсовых погромиздов и делают. А дружить - это же ДУМАТЬ надоть. Нафих вообще... - =AlexD=(15.07.2024 15:33)
        
        Не знаю про моду. Tyмблep(1344 знак., 16.07.2024 15:20)
        
        Ну, полюбому, реализовать "отличие...числовой константой" вы должны ручками. Сами. А, потом, гордо, пользоваться получившимся объектом. Хотя, чисто механически, смысла в этом осталось не так чтобы много. - mse homjak(16.07.2024 15:48)
        
        Ещё бы ! Tyмблep(440 знак., 16.07.2024 17:38)
        
        Не понял, почему "ручками гораздо дольше"? Не, можно упороться на ровном месте, моё почтение. Спору нет. Но если у вас ужэ есть набор параметризируемых функцый, то что за проблема просто передавать в ужэ написанную функцыю параметр, соотвецтвующий конкретной микруле? mse homjak(324 знак., 16.07.2024 17:59)
        
        Как бы почти же самое. Tyмблep(1795 знак., 16.07.2024 18:18)
        
        Ну и? Все процедуры должны быть вами написаны! Под требования ООП. Все "классы-предки", это просто абстракция. Физически, это, условно, функция, в которую передаётся условный указатель на список параметров конкретного жука. Которая вами написана. Вся роль "классовой боротьбы", это передача параметров(которые вы ужэ подготовили) в функции(котрые вы ужэ написали). Это всё хорошо и выгодно, если всю работу за вас сделал дядя, а вы только пользуетесь. Но дядя, как правило, не в mse homjak(49 знак., 16.07.2024 19:54)
        
        Просто хаос в голове. Tyмблep(1531 знак., 22.07.2024 16:43)
        
        Вы полюбому напишете эти процэдуры с параметрами, в том или ином виде. mse homjak(703 знак., 22.07.2024 18:27)
        
        А вы хотели, чтобы процедуры сами собой взошли, без труда ? Типа крекс-фекс-пекс - и готово ? Tyмблep(343 знак., 22.07.2024 20:10)
        
        Ну? Я-жэ и говорю:"жмёшь кнопку, мешок на спине, жмёшь другую, спина в мыле". mse homjak(138 знак., 22.07.2024 20:55)
        
        Бывает. У меня именно так. Без всех этих огромных (но бесполезных) надстроек. Cкpипaч(323 знак., 22.07.2024 20:19)
        
        Что бывает ? Tyмблep(194 знак., 22.07.2024 20:22)
        
        Бывает - "типа крекс-фекс-пекс - и готово". Cкpипaч(152 знак., 22.07.2024 20:32)
        
        СТМовский Куб обходится как-то без этого мракобесия. И его применение не вызывает особых затруднений. Есть претензия к качеству кода, но этодругое. - =AlexD=(22.07.2024 16:55)
        
        Кстати, интересный вопрос, почему в КУБ-е не использовали эти возможности С++? - AlexBi(22.07.2024 18:53)
        
        А смысл? Делать две разные либы - одна на Си, другая на С++? Не, ну сделать свои обёртки они конечно могут, но видимо не видят смысла в лишней работе. - =AlexD=(23.07.2024 09:27)
        
        Вероятно, я знаю эту тайну. Tyмблep(732 знак., 22.07.2024 20:47)
        
        Опытные программисты знают что если пишешь не для себя, а для использования другими, то лучше не применять всю мощь плюсов без особой необходимости. Иначе потом замучают вопросами "как это использовать?" и воплями "ничего не понятно" и "ничего не работает". А сделать библиотеку которую смогут использовать не заглядывая внутрь - это ещё более сложная задача, особенно когда процессор в 200 раз медленнее и памяти в миллион раз меньше. - ЫЫyкпy(23.07.2024 08:46)
        
        Основная проблема объектных библиотек (вне зависимости от языка) в том, что авторы не могут предусмотреть все варианты использования. А чаще всего возникает необходимость использовать какую-то часть библиотеки отдельно, вне иерархии. Например не на поток данных, а на файл или структуру в памяти. Процедурные библиотеки в этом плане проще, там только с хедерами могут накосячить, напихав в них всё что ни попадя. Но с этим можно бороться. С иерархией классов уже ничего не сделать =AlexD=(1 знак., 23.07.2024 09:24)
        
        С++ с современными возможностями, метапрограммированием выглядит не таким простым как С - AlexBi(22.07.2024 23:39)
        
        А что это даст? (ну кроме самого по себе "использования") - Cкpипaч(22.07.2024 20:18)
        
        Программа станет более понятной, меньше по объему, написанному руками (код КУБа не учитываем), лучше контроль ошибок несовместимости настроек (заполняя разные структуры легко ошибиться), результирующий код меньше/быстрее (оптимизатор еще не так крут, на сколько мне известно) - AlexBi(22.07.2024 23:36)

Средства и методы разработки