2010-02-12 18 views
8

¿Alguien puede elaborar el patrón de diseño de puente y el patrón de decorador para mí? Lo encontré similar de alguna manera. No sé cómo distinguirlo?patrón de puente en comparación con el patrón de decorador

Según tengo entendido, en Bridge, se separa la implementación de la interfaz, generalmente solo se puede aplicar una implementación. Decorator es una especie de envoltorio, puedes envolver tantas como puedas.

Por ejemplo,

patrón de puente

class Cellphone { 
private: 
Impl* m_OS;   // a cellphone can have different OS 

} 

Decorator

class Shirt { 
private: 
Person * m_p;   //put a shirt on the person; 

} 

Respuesta

15

El decorador debe coincidir con la interfaz del objeto que se está decorando. es decir, tiene los mismos métodos, y permite la interceptación de los argumentos sobre el camino de entrada y el resultado a la salida. Puede usar esto para proporcionar un comportamiento adicional al objeto decorado mientras mantiene la misma interfaz/contrato. Tenga en cuenta que la interfaz del Decorador puede proporcionar funcionalidad adicional para crear un objeto más útil.

El puente no tiene tal restricción. La interfaz de cara al cliente puede ser diferente del componente subyacente que proporciona la aplicación, y por lo tanto puentes entre la interfaz del cliente, y la ejecución real (que puede no ser cliente-amistoso, sujeto a cambios, etc.)

+0

decorador también puede añadir métodos de conveniencia a la interfaz que se está decorando. –

+0

Sí. Ese es un muy buen punto.Me había olvidado que –

5

su aplicación decorator no está del todo bien - no tendría más sentido si lo hizo:

class PersonWearingShirt : IPerson 
{ 
private: 
    IPerson * m_p;   //put a shirt on the person; 

} 

la idea es que, cuando decorar una clase, se expone la misma interfaz exacta. Esto hace que su instancia "decorada" se vea y actúe como la original. Esto le permite ajustar una instancia muchas veces con decoradores múltiples, pero la trata exactamente igual que cuando trata la instancia original.

+0

derecha, me di cuenta de que después de publicar. – skydoor

+0

¿Cómo difiere esto del patrón de diseño Proxy? –

+0

Decorator está destinado a agregar funcionalidad, "envolviendo" un objeto existente. Se pueden asignar decoradores múltiples alrededor de un solo objeto (es decir: cada uno envuelve el anterior). Proxy básicamente actúa como un intermediario, adaptándolo por alguna razón, a menudo para manejar algún tipo de función (asignación de recursos), carga de retraso, etc., pero por lo general, usted tiene un proxy para proporcionar indirectamente acceso a una instancia. –

1

Brian es el correcto. Añadiré eso conceptualmente, el cliente "sabrá" que está usando un puente para un objeto subyacente, pero con un decorador, el cliente no podrá saber que hay una capa de decorador entre él y el objeto de destino.

El propósito del puente es crear una capa de abstracción para proteger al cliente. El propósito del decorador es agregar funcionalidad al objeto sin que el cliente lo sepa. La mayoría de los decoradores pasarán todas las llamadas de función directamente a un puntero a su clase principal, a excepción de las funciones relacionadas directamente con lo que el decorador está diseñado para cambiar.

1

decorador:

  1. Añadir comportamiento a oponerse en tiempo de ejecución. La herencia es la clave para lograr esta funcionalidad, que es a la vez ventaja y desventaja de este patrón.
  2. Mejora el comportamiento de la interfaz.
  3. Decorator se puede ver como un compuesto degenerado con solo un componente. Sin embargo, un Decorador agrega responsabilidades adicionales, no está destinado a la agregación de objetos.
  4. Decorador admite composición recursiva
  5. La clase Decorador declara una relación de composición con la interfaz LCD (denominador de clase más bajo) y este miembro de datos se inicializa en su constructor.
  6. decorador está diseñado para permitir añadir responsabilidades a objetos sin subclasificar

Consulte sourcemaking artículo para más detalles.

diagrama UML del decorador de wikipedia: Modelo

enter image description here

Puente:

  1. puente es patrón estructural
  2. la abstracción y la aplicación no están obligados en tiempo de compilación
  3. Abstracción e implementación ación - ambos pueden variar sin impacto en el cliente

Utilice el patrón de puente cuando:

  1. desea ejecutar el enlace en tiempo de la aplicación,
  2. que tienen una proliferación de clases que resultan de un acoplado interfaz y numerosas implementaciones,
  3. desea compartir una implementación entre varios objetos, necesita asignar jerarquías de clases ortogonales.

diagrama UML del puente de wikipedia:

enter image description here

De diagrama UML, se puede observar la diferencia:

en el patrón decorador, decorador es la implementación de componentes, que se ser reemplazado por ConcreteComponent en el tiempo de ejecución.

En patrón de puente, RedefinedAbstraction no implementa Implementor. En cambio, usa la composición para que el implementador pueda variar dinámicamente en tiempo de ejecución sin conocimiento del cliente.

Decorator no puede desacoplar la abstracción de la implementación a diferencia del patrón Bridge.

pocos puestos más útiles:

When to Use the Decorator Pattern?

When do you use the Bridge Pattern? How is it different from Adapter pattern?

Cuestiones relacionadas