На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
[!] Как относитесь к модерированию на этом форуме? Выскажите свое мнение здесь
Модераторы: Qraizer
  
> Обсудим паттерн проектирования "Мост" (Bridge) на C++
    Приветствую!

    Сразу дам линк на неплохую статью.

    user posted image

    Хотелось бы услышать ваши личные мнения по вопросам:

    1) В статье описано множество достоинств данного паттерна проектирования. Какие первые три вы считаете самыми-самыми важными?
    2) Есть ли что-то в данном подходе, что иными механизмами ООП реализовать было нельзя в принципе?
    3) Какие особенности проектируемых моделей однозначно "говорят", что использование данного паттерна проектирования нужно - 100%?
      Цитата JoeUser @
      1) В статье описано множество достоинств данного паттерна проектирования. Какие первые три вы считаете самыми-самыми важными?

      Самое важное - это его основное назначение.

      Добавлено
      Цитата JoeUser @
      3) Какие особенности проектируемых моделей однозначно "говорят", что использование данного паттерна проектирования нужно - 100%?

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

      Например, в том же примере с логгером.
      Допустим, у юзера сбой в программе, он видит лог-файл, обращается в поддержку.
      Оттуда ему присылают dll и просят поместить в папку с приложением.
      Приложение чует знакомую dll, явно загружает eё, запускает какой-нибудь "Create",
      получает указатель на интерфейс логгера.
      Логгер получает указатель и начинает выводить через этот интерфейс.
      Разработчик наблюдает проблемы в реальном времени на своём айфоне.

      Или, предположим, мы делаем контролы, которые могут сохранять/восстанавливать своё
      своё состояние. Это очень удобно.
      Если сделать статическую модель, поведение контролов всегда одно и тоже.
      В случае с применением указанных технологий, можно, передавая реализацию интерфейса сохранения:
      1. работать с ini - файлом
      2. работать с реестром
      3. с обоими
      4. Ни с кем не работать, если спасать/восстанавливать состояние конкретному контролу не нужно.

      Только такие возможности в приведённом к статье примере
      не показаны, что делает его не совсем удачным.
      Сообщение отредактировано: ЫукпШ -
        В статье написано что "приведенная реализация" "использует идиому pimpl".
        А как можно этот патерн реализовать по-другому (допустим без pimpl)?
          Цитата JoeUser @
          А как можно этот патерн реализовать по-другому (допустим без pimpl)?

          Не совсем понял вопрос...
          То, что классу Логгер необходимо дать описание абстрактного класса-интерфейса,
          не вызывает сомнений.
          Это же его "рабочая лопата" !
          Скрытый текст

          Только я бы так делать не стал.
          Я бы попробовал так:
          1. Описал абстрактный класс - интерфейс. ILoggerImp. Допустим, с методом "LoggerAction".
          2. Спокойно скормил бы его классу Логгер.
          3. Унаследовался бы от класса-интерфейса классом IConsolImp. (ITcpImp,IDebugViewImp, IFileImp, ITcpAndFileImp итд)
          4. Про эти конкретные реализации Логгер ничего не знает.
          5. Создаём экземпляр Логгера. Пока ему не передали указатель на реализацию интерфейса, он работать не может.
          Но это ещё не криминал.
          6. Создали какой-то экземпляр реализации интерфейса. Например, IConsolImp.
          Преобразовали тип его указателя к типу указателя ILoggerImp.
          Если надо, настроили предварительно все параметры экземпляра IConsolImp.
          7. Передали классу Логгер указатель из пункта 6.
          Всё. Логгер может работать в консоль.
          Если заменим ему указатель - Логгер сможет выводить в другое место.
          Например в файл и на сервер посредством ITcpAndFileImp.
          Сообщение отредактировано: ЫукпШ -
            Вообще, в C++ эта штюка носит название pimpl (Private Implementation), в которой публичный класс и является этим самым мостом, фиксирующим публичный интерфейс. Сейчас вот аналогичную штуку хочу делать для генерилки автотестов.
              Pointer to Implementation
                Qraizer, я как-то мельком читал (просто запомнилось, могу ошибаться) ... Упоминалась аббревиатура "ppimpl". Сможешь раскидать на пальцах для FAQ, естественно, если я не ошибаюсь?
                  Если это был я, то это "Pointer to PImpl". Я сам её придумал.
                  Одна из выгод от pimpl заключается в полной сокрытии реализации, что делает ненужным перекомпиляцию клиентов при смене реализации в impl, потребуется только перелинковка, т.к. сам pimpl-овый класс связан с impl-овым. В случае ppimpl даже перелинковки может не потребоваться, т.к. клиенты работают с pimpl-овым классом не явно, а по указателю, и следовательно даже опосредовано не зависят impl. (Перелинкова самого pimpl-а, конечно, может потребоваться.) Это очень удобно в случае динамических библиотек. Пересборка библиотеки, если она экспортирует ppimpl, не требует никаких телодвижений от пользующихся ею клиентов, чьи бинарники остаются работоспособными с новыми версиями этой библиотеки.
                    Цитата Qraizer @
                    Я сам её придумал.

                    Qraizer, да, скорее всего твой термин. Идею осознал. Для динамической линковки - вполне себе! Сенкс!
                    0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                    0 пользователей:


                    Рейтинг@Mail.ru
                    [ Script execution time: 0,0467 ]   [ 17 queries used ]   [ Generated: 29.03.24, 12:10 GMT ]