Когда вы используете паттерн «Мостик»? Чем он отличается от шаблона адаптера?

Классический пример паттерна «Мост» используется при определении фигур в среде пользовательского интерфейса (см. Образец моста запись в Википедии). Шаблон моста - это составной из шаблонов Шаблон и Стратегия.

Это обычное представление о некоторых аспектах паттерна «Адаптер» в паттерне «Мост». Однако, если процитировать эта статья:

At first sight, the Bridge pattern looks a lot like the Adapter pattern in that a class is used to convert one kind of interface to another. However, the intent of the Adapter pattern is to make one or more classes' interfaces look the same as that of a particular class. The Bridge pattern is designed to separate a class's interface from its implementation so you can vary or replace the implementation without changing the client code.

Паттерн «Мост» - это применение старого совета «предпочитать композицию наследованию». Это становится удобным, когда вы должны создавать подклассы для разных времен ортогонально друг другу. Скажем, вы должны реализовать иерархию цветных фигур. Вы бы не стали подклассом Shape с Rectangle и Circle, а затем подклассом Rectangle с RedRectangle, BlueRectangle и GreenRectangle и то же самое для Circle, не так ли? Вы бы предпочли сказать, что каждая форма имеет имеет цвет, и реализовать иерархию цветов, и это шаблон моста. Ну, я бы не стал реализовывать «иерархию цветов», но вы поняли ...

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

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

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

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

Итак, с точки зрения кода эти два шаблона очень похожи. С точки зрения бизнеса они разные.

См. Также http://c2.com/cgi/wiki?BridgePattern

Я использовал схему моста в работе. Я программирую на C++, где это часто называют идиомой PIMPL (указатель на реализацию). Это выглядит так:

class A
{
public: 
  void foo()
  {
    pImpl->foo();
  }
private:
  Aimpl *pImpl;
};

class Aimpl
{
public:
  void foo();
  void bar();
};  

В этом примере class A содержит интерфейс, а class Aimpl - реализацию.

Одно из применений этого шаблона - раскрытие только некоторых общедоступных членов класса реализации, но не других. В примере только Aimpl::foo() может вызываться через публичный интерфейс A, но не Aimpl::bar().

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

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

И совет: всегда думайте о шаблонах проектирования с концептуальной точки зрения, а не с точки зрения реализации. С правильной точки зрения, Bridge нельзя путать с адаптером, потому что они решают другую проблему, а композиция превосходит наследование не ради себя, а потому, что позволяет обрабатывать ортогональные проблемы по отдельности.

Когда:

        A
     /     \
    Aa      Ab
   / \     /  \
 Aa1 Aa2  Ab1 Ab2

Выполните рефакторинг для:

     A         N
  /     \     / \
Aa(N) Ab(N)  1   2

Есть комбинация ответов Федерико и Джона.

Когда:

                   ----Shape---
                  /            \
         Rectangle              Circle
        /         \            /      \
BlueRectangle  RedRectangle BlueCircle RedCircle

Выполните рефакторинг для:

          ----Shape---                        Color
         /            \                       /   \
Rectangle(Color)   Circle(Color)           Blue   Red

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

Чтобы поместить пример формы в код:

#include<iostream>
#include<string>
#include<cstdlib>

using namespace std;

class IColor
{
public:
    virtual string Color() = 0;
};

class RedColor: public IColor
{
public:
    string Color()
    {
        return "of Red Color";
    }
};

class BlueColor: public IColor
{
public:
    string Color()
    {
        return "of Blue Color";
    }
};


class IShape
{
public:
virtual string Draw() = 0;
};

class Circle: public IShape
{
        IColor* impl;
    public:
        Circle(IColor *obj):impl(obj){}
        string Draw()
        {
            return "Drawn a Circle "+ impl->Color();
        }
};

class Square: public IShape
{
        IColor* impl;
    public:
        Square(IColor *obj):impl(obj){}
        string Draw()
        {
        return "Drawn a Square "+ impl->Color();;
        }
};

int main()
{
IColor* red = new RedColor();
IColor* blue = new BlueColor();

IShape* sq = new Square(red);
IShape* cr = new Circle(blue);

cout<<"\n"<<sq->Draw();
cout<<"\n"<<cr->Draw();

delete red;
delete blue;
return 1;
}

Результат:

Drawn a Square of Red Color
Drawn a Circle of Blue Color

Обратите внимание на легкость, с которой новые цвета и формы могут быть добавлены в систему, не приводя к взрывному росту подклассов из-за перестановок.

Bridge design pattern we can easily understand helping of service and dao layer.

Dao layer -> create common interface for dao layer ->
public interface Dao<T>{
void save(T t);
}
public class AccountDao<Account> implement Dao<Account>{
public void save(Account){
}
}
public LoginDao<Login> implement Dao<Login>{
public void save(Login){
}
}
Service Layer ->
1) interface
public interface BasicService<T>{
    void save(T t);
}
concrete  implementation of service -
Account service -
public class AccountService<Account> implement BasicService<Account>{
 private Dao<Account> accountDao;
 public AccountService(AccountDao dao){
   this.accountDao=dao;
   }
public void save(Account){
   accountDao.save(Account);
 }
}
login service- 
public class LoginService<Login> implement BasicService<Login>{
 private Dao<Login> loginDao;
 public AccountService(LoginDao dao){
   this.loginDao=dao;
   }
public void save(Login){
   loginDao.save(login);
 }
}

public class BridgePattenDemo{
public static void main(String[] str){
BasicService<Account> aService=new AccountService(new AccountDao<Account>());
Account ac=new Account();
aService.save(ac);
}
}
}

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

Вы начинаете свой дизайн с этих классов:

public class Task {...}
public class AccountingTask : Task {...}
public class ContractTask : Task {...}
public class ClaimTask : Task {...}

Теперь, поскольку каждый источник должен обрабатываться определенным образом, вы решаете специализировать каждый тип задачи:

public class EmailAccountingTask : AccountingTask {...}
public class FaxAccountingTask : AccountingTask {...}
public class EmessagingAccountingTask : AccountingTask {...}

public class EmailContractTask : ContractTask {...}
public class FaxContractTask : ContractTask {...}
public class EmessagingContractTask : ContractTask {...}

public class EmailClaimTask : ClaimTask {...}
public class FaxClaimTask : ClaimTask {...}
public class EmessagingClaimTask : ClaimTask {...}

У вас осталось 13 классов. Добавление типа задачи или типа источника становится сложной задачей. Использование шаблона моста упрощает обслуживание, отделяя задачу (абстракцию) от источника (что является проблемой реализации):

// Source
public class Source {
   public string GetSender();
   public string GetMessage();
   public string GetContractReference();
   (...)
}

public class EmailSource : Source {...}
public class FaxSource : Source {...}
public class EmessagingSource : Source {...}

// Task
public class Task {
   public Task(Source source);
   (...)
}
public class AccountingTask : Task {...}
public class ContractTask : Task {...}
public class ClaimTask : Task {...}

Добавить тип задачи или источник стало намного проще.

Примечание. Большинство разработчиков не создают иерархию из 13 классов заранее для решения этой проблемы. Однако в реальной жизни вы можете не знать заранее количество источников и типов задач; если у вас есть только один источник и два типа задач, вы, вероятно, не будете отделять задачу от источника. Затем общая сложность растет по мере добавления новых источников и типов задач. В какой-то момент вы проведете рефакторинг и, чаще всего, получите решение, подобное мосту.