Схема прокладки моста и адаптера

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

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

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

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

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

По моему мнению, оба шаблона указывают на существующий тип, оба отделяют абстракцию от его реализации. Я пропущу точку?

Здесь из GoF:

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

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

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

Update:

Опять из GoF:

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

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

Update2:

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

Об этом ранее говорилось здесь - Разница между мостом и шаблоном адаптера - Настоящая цитата, которую вы хотите от GoF, -" Адаптер делает работу после того, как они разработаны, Bridge заставляет их работать до того, как они будут. [GoF, p219]

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

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