Bridge против адаптера Design Pattern

Question

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

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

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

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

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

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

Вот от GoF:

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

Я не полностью понимаю вышеуказанное заявление,

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

Update:

Опять из GoF:

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

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

Update2:

Просто найти эту невероятную статью: Illustrated GOF Design Patterns in C#

Это истинная структура моста Скороговорки:

я пропускал тот факт, что модель Bridge позволяет комбинировать различные абстракции и реализацию и удлинить их независимо

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Это было ранее обсуждалось здесь - Difference between Bridge pattern and Adapter pattern - Реальная цитата вы хотите от GoF является «адаптер делает вещи работать после того, как они разработаны, мост делает их работу, прежде чем они [GoF, P219]

.

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

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