Мост против шаблона проектирования адаптера

Мой коллега спросил меня о шаблоне проектирования моей реализации службы Windows WCF в клиентском приложении ASP.net, и я действительно не мог сказать, является ли это мост или адаптер !

Вот реализация:

  • Я получил договор на обслуживание
  • Определен новый интерфейс, похожий на мой контракт данных WCF
  • Я создал клиент WCF и обернул его в новый интерфейс.
  • Сопоставил новые операции интерфейса с исходным клиентом WCF (здесь я веду журнал и обрабатываю ошибки)

Я всегда думал об этом как о реализации шаблона Адаптер, но на самом деле не могу сказать, почему это не Мост!

Я прочитал все сообщения здесь, в SO, GoF и википедии, но это действительно бессмысленно!

Насколько я понимаю, оба шаблона указывают на существующий тип, оба отделяют абстракцию от ее реализации, я упустил момент?

Вот от GoF:

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

Я не совсем понимаю приведенное выше утверждение,

  1. Означает ли это, что если я изменю адаптируемый объект или изменю реализацию исходного интерфейса во время разработки, то это будет Шаблон моста?
  2. Различия звучат банально, есть ли другие отличия в реализации / абстракции?
  3. Как узнать, какая реализация используется после разработки?
  4. Может ли кто-нибудь дать мне хороший пример шаблона моста и того, как его можно изменить в течение жизненного цикла программного обеспечения?

Обновлять:

Опять же из GoF:

Помните, что адаптер заставляет два существующих интерфейса работать вместе, а не определять совершенно новый.

Означает ли это, что изменение существующего интерфейса таким образом, чтобы он мог работать с другим интерфейсом, является реализацией адаптера?

Обновление2:

Только что нашел эту невероятную статью: Иллюстрированные шаблоны проектирования GOF на C #

Это настоящая структура Bridge Patter:

Мне не хватало того факта, что шаблон «Мост» позволяет комбинировать различные абстракции и реализации и расширять их независимо введите описание изображения здесь


c# design-patterns wcf adapter bridge
person Kamyar Nazeri    schedule 17.05.2012    source источник

Ответы (3)


arrow_upward
6
arrow_downward

Я думаю, у вас здесь нет чистого шаблона GoF. Это что-то среднее между декоратором и адаптером. Вы меняете интерфейс клиента сервиса (адаптируете его под свои нужды). Но также вы добавляете новые обязанности к клиенту (ведение журнала и обработка ошибок) - это часть украшения. Если бы вы остались с оригинальным интерфейсом сервиса, это был бы чистый Decorator.

ОБНОВЛЕНИЕ: любое использование наследования не означает, что мы используем какой-то шаблон GoF. Есть несколько вещей, которых не хватает вашей текущей архитектуре, чтобы быть мостом:

  • Иерархия реализаций. Интерфейс вашего сервиса должен определять некоторые низкоуровневые операции. И у вас должно быть несколько реализаций сервиса.
  • Абстракция должна определять высокоуровневый интерфейс. Обычно эти интерфейсы не похожи на интерфейс реализации (ваш клиентский интерфейс похож на интерфейс службы, он существует на том же уровне абстракции).
  • Реализации абстракции должны использовать сервисный интерфейс для реализации высокоуровневых операций (т.е.они не добавляют некоторые обязанности к сервису, они реализуют разные вещи, высокоуровневые вещи).
person Sergey Berezovskiy    schedule 17.05.2012
comment
Да, вы правы в части декоратора, однако по определению кажется, что это шаблон моста, поскольку контракт службы WCF развивается в течение жизненного цикла программного обеспечения! - person Kamyar Nazeri; 17.05.2012
comment
Мост используется для соединения двух иерархий классов. Я не вижу здесь никакой иерархии. - person Sergey Berezovskiy; 17.05.2012

arrow_upward
5
arrow_downward

Мне объяснили, что шаблон «мост» - это намерение объединить две иерархии классов с разными целями. Например, рассмотрим, что вы пишете оконную структуру с различными типами элементов управления и поддержкой разных оконных систем. У вас будет одно дерево классов для элементов управления, а другое - для абстрагирования различий между оконными системами. Теперь, если вы хотите добавить поддержку другой оконной системы, вы просто добавляете ее на эту сторону иерархии, а если вы хотите добавить новые элементы управления, вы добавляете их на их сторону. «Мост» существует между верхними классами двух иерархий, где ваш класс управления имеет доступ к абстрактным функциям, определенным базовым классом иерархии классов, реализующим поддержку различных оконных систем.

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

person Wormbo    schedule 17.05.2012

arrow_upward
4
arrow_downward

Это уже обсуждалось здесь ранее - Разница между шаблоном моста и шаблоном адаптера - Настоящая цитата от GoF: «Адаптер заставляет вещи работать после того, как они спроектированы; Bridge заставляет их работать раньше, чем они есть». [GoF, p219]

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

Шаблон моста обычно используется для решения проблем на начальном этапе проектирования, когда ментальная модель, представленная потребителю, может сильно отличаться от модели, которая реализует реализацию модели потребителей. Рассмотрим высокопроизводительную математическую библиотеку, которая выглядит одинаково для самых разных процессоров - вы просто хотите умножить матрицы, но за кулисами есть все виды беспорядка, включая свизлинг, параллельные потоки данных, странное поведение, позволяющее избежать остановок конвейера, и все готово. по-разному на 3+ реализациях высокопроизводительного суперскейлера - и это просто Intel :-(

person Mark Mullin    schedule 17.05.2012