Lorsque vous utilisez le Pont de Modèle? Comment est-il différent de l'Adaptateur?

Un exemple classique du Pont motif est utilisé dans la définition des formes dans l'INTERFACE utilisateur de l'environnement (voir la Pont modèle entrée de Wikipedia). Le Pont motif est un composite de la Modèle et Stratégie modèles.

C'est un point de vue commun de certains aspects de l'Adaptateur dans le Pont de modèle. Cependant, pour citer cet article:

À première vue, le Pont de modèle ressemble beaucoup au motif Adaptateur dans une classe est utilisée pour convertir en une sorte d'interface à l'autre. Cependant, l'intention de l'Adaptateur est de faire une ou plusieurs classes, les interfaces de regarder la même que celle d'une classe particulière. Le Pont motif est conçu pour séparer une classe de l'interface à partir de sa mise en œuvre, de sorte que vous pouvez modifier ou de remplacer l'application sans modifier le code du client.

Le Pont motif est une application de l'ancien conseil, préférez la composition au cours de l'héritage".
Il devient utile lorsque vous devez sous-classe des moments différents, dans des façons qui sont orthogonaux l'un à l'autre. Dire que vous devez mettre en œuvre une hiérarchie de formes colorées. Vous n'auriez pas sous-classe de la Forme avec le Rectangle et le Cercle, et de la sous-classe Rectangle avec RedRectangle, BlueRectangle et GreenRectangle et de même pour le Cercle, le feriez-vous? Vous préférez-à-dire qu'à chaque Forme a une Couleur et à mettre en œuvre une hiérarchie des couleurs, et c'est le Pont de Modèle. Eh bien, je ne voudrais pas mettre en œuvre une "hiérarchie des couleurs", mais vous voyez l'idée...

L'adaptateur et le Pont sont certainement liés, et la distinction est subtile. Il est probable que certaines personnes qui pensent qu'ils sont à l'aide de l'un de ces modèles sont en fait à l'aide de l'autre modèle.

L'explication que j'ai vu, c'est que l'Adaptateur est utilisé lorsque vous essayez d'unifier les interfaces de certaines incompatible classes qui existent déjà. La Carte fonctionne comme une sorte de traducteur à des implémentations qui pourrait être considéré comme héritage.

Alors que le Pont motif est utilisée pour le code qui est plus susceptible d'être greenfield. Vous êtes à la conception du Pont de fournir une interface abstraite pour une mise en œuvre qui doit varier, mais vous pouvez également définir l'interface de ces classes d'implémentation.

Pilotes de périphérique est souvent citée comme un exemple de Pont, mais je dirais que c'est un Pont si vous êtes à la définition de l'interface de spécification pour les fournisseurs d'appareils, mais c'est un Adaptateur si vous prenez des pilotes de périphériques existants et de faire un wrapper-classe afin de fournir une interface unifiée.

Donc le code-sage, les deux modèles sont très similaires. Entreprise sages, ils sont différents.

Voir aussi http://c2.com/cgi/wiki?BridgePattern

L'intention de Pont et Adaptateur est différent, et nous avons besoin des deux modèles séparément.

Pont motif:

1. C'est un modèle structurel
2. D'Abstraction et de mise en œuvre ne sont pas liés au moment de la compilation
3. D'Abstraction et de mise en œuvre - les deux peuvent varier sans impact au client
4. Utilise la composition au cours de l'héritage.

Utiliser le Pont modèle:

1. Vous souhaitez exécuter liaison au moment de la mise en œuvre,
2. Vous avez une prolifération des classes résultant de couplage de l'interface et de nombreuses implémentations,
3. Vous voulez partager une mise en œuvre entre plusieurs objets,
4. Vous avez besoin de la carte orthogonale de hiérarchies de classes.

@ John Sonmez réponse montre clairement l'efficacité de pont modèle dans la réduction de la hiérarchie de classe.

Vous pouvez consulter ci-après la documentation lien pour obtenir un meilleur aperçu de pont modèle avec le code exemple

L'adaptateur:

1. Il permet à deux indépendants des interfaces de travailler ensemble à travers les différents objets, éventuellement jouer le même rôle.
2. Il modifie l'interface originale.

Principales différences:

1. Adaptateur fait fonctionner les choses une fois qu'elles ont été conçues; Pont fait travailler avant qu'ils sont.
2. Pont est conçu au départ pour laisser la l'abstraction et de la mise en œuvre varient indépendamment. Adaptateur est équipé pour rendre les classes indépendantes de travailler ensemble.
3. L'intention : Adaptateur permet à deux indépendants des interfaces de travailler ensemble. Pont permet d'Abstraction et de mise en œuvre de varier de manière indépendante.

Liées SE question avec le diagramme UML et le code de travail:

La différence entre le Pont du motif et de l'Adaptateur

Des articles utiles:

sourcemaking pont modèle de l'article

sourcemaking adaptateur modèle de l'article

journaldev pont modèle de l'article

EDIT:

Pont Modèle de l'exemple du monde réel ( Comme par meta.stackoverflow.com suggestion, la documentation du site exemple dans ce post, puisque la documentation sun-set)

Pont motif découple l'abstraction de la mise en œuvre afin que les deux peuvent varier de manière indépendante. Il a été réalisé avec la composition plutôt que de l'héritage.

Pont de modèle UML à partir de Wikipedia:

Vous avez quatre composantes de ce modèle.

Abstraction: Il définit une interface

RefinedAbstraction: Il met en œuvre l'abstraction:

Implementor: Il définit une interface pour la mise en œuvre

ConcreteImplementor: Il met en oeuvre chargé de l'implémentation de l'interface.

The crux of Bridge pattern : Deux orthogonaux les hiérarchies de classe à l'aide de la composition (et pas d'héritage). La hiérarchie d'Abstraction et de mise en Œuvre de la hiérarchie peut varier de manière indépendante. La mise en œuvre ne se réfère jamais à l'Abstraction. Abstraction contient de la mise en Œuvre de l'interface en tant que membre (par composition). Cette composition réduit encore un niveau de la hiérarchie d'héritage.

Mot réel de cas d'Utilisation:

Permettre de véhicules différents à avoir les deux versions du manuel et automatique système d'engrenage.

Exemple de code:

/* Implementor interface*/
interface Gear{
void handleGear();
}
/* Concrete Implementor - 1 */
class ManualGear implements Gear{
public void handleGear(){
System.out.println("Manual gear");
}
}
/* Concrete Implementor - 2 */
class AutoGear implements Gear{
public void handleGear(){
System.out.println("Auto gear");
}
}
/* Abstraction (abstract class) */
abstract class Vehicle {
Gear gear;
public Vehicle(Gear gear){
this.gear = gear;
}
abstract void addGear();
}
/* RefinedAbstraction - 1*/
class Car extends Vehicle{
public Car(Gear gear){
super(gear);
//initialize various other Car components to make the car
}
public void addGear(){
System.out.print("Car handles ");
gear.handleGear();
}
}
/* RefinedAbstraction - 2 */
class Truck extends Vehicle{
public Truck(Gear gear){
super(gear);
//initialize various other Truck components to make the car
}
public void addGear(){
System.out.print("Truck handles " );
gear.handleGear();
}
}
/* Client program */
public class BridgeDemo {    
public static void main(String args[]){
Gear gear = new ManualGear();
Vehicle vehicle = new Car(gear);
vehicle.addGear();
gear = new AutoGear();
vehicle = new Car(gear);
vehicle.addGear();
gear = new ManualGear();
vehicle = new Truck(gear);
vehicle.addGear();
gear = new AutoGear();
vehicle = new Truck(gear);
vehicle.addGear();
}
}

de sortie:

Car handles Manual gear
Car handles Auto gear
Truck handles Manual gear
Truck handles Auto gear

Explication:

1. Vehicle est une abstraction.
2. Car et Truck sont deux des implémentations concrètes de Vehicle.
3. Vehicle définit une méthode abstraite : addGear().
4. Gear est chargé de l'implémentation de l'interface
5. ManualGear et AutoGear sont deux implémentations de Gear
6. Vehicle contient implementor interface plutôt que la mise en œuvre de l'interface. Compositon de chargé de l'implémentation de l'interface est le point crucial de ce modèle : Il permet d'abstraction et de mise en œuvre de varier de manière indépendante.
7. Car et Truck définir la mise en œuvre ( redéfini l'abstraction) pour le prélèvement : addGear() : Il contient Gear - Soit Manual ou Auto

Cas d'utilisation(s) pour Pont motif:

1. Abstraction et mise en Œuvre pouvez modifier indépendants les uns des autres et ils ne sont pas liés au moment de la compilation
2. Carte orthogonale de la hiérarchie - Un pour Abstraction et un pour mise en Œuvre.

De mettre en forme l'exemple de code:

#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;
}

La sortie est:

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

Noter la facilité avec laquelle de nouvelles couleurs et de formes peut être ajouté au système, sans aboutir à une explosion de la sous-classes en raison de permutations.

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);
}
}
}