Puente vs. adaptador de patrones de diseño

Question

fui interrogado por un colega sobre el patrón de diseño de mi implementación de un servicio WCF ventanas en una aplicación cliente ASP.net y realmente no podría decir si es Puente o adaptador !

Aquí es la implementación:

• he obtenido el contrato de servicio
• definido una nueva interfaz similar a mi contrato de datos de WCF
• creé un cliente WCF y lo envolvió dentro de la nueva interfaz
• mapean las nuevas operaciones de interfaz con el cliente WCF originales (hago un poco de registro/manejo de error aquí)

Siempre estuve pensando en ello como una implementación de Adaptador patrón, pero realmente no puedo decir por qué no es Puente!

He leído todas las publicaciones aquí en SO, GoF y wikipedia, ¡pero realmente no tiene sentido!

Desde mi entender, Ambos patrones de puntos en un tipo existente, tanto desacoplar una abstracción de su implementación me estoy perdiendo un punto?

Aquí es de GoF:

La diferencia clave entre estos patrones radica en sus intenciones. El adaptador se enfoca en resolver incompatibilidades entre dos interfaces existentes. No se centra en cómo se implementan esas interfaces, , ni considera cómo podrían evolucionar de forma independiente. Es una manera de hacer que dos clases diseñadas independientemente funcionen juntas sin volver a implementar una u otra. Bridge, por otro lado, une una abstracción y sus (potencialmente numerosas) implementaciones. Es proporciona una interfaz estable para los clientes, incluso si le permite variar las clases que lo implementan. También acomoda nuevas implementaciones como , el sistema evoluciona.

No entiendo plenamente la declaración anterior,

1. ¿Quiere decir que si varío el adaptado o cambiar la aplicación de la interfaz original en tiempo de diseño, entonces es Patrón Puente ?
2. Las diferencias suenan triviales, ¿Hay alguna otra diferencia en la implementación/abstcation de ?
3. ¿Cómo puede alguien decir qué implementación se usa después de desarrollo?
4. ¿Alguien me puede dar un buen ejemplo de patrón de puente y cómo puede cambiarse durante el ciclo de vida del software?

Actualización:

nuevo desde GoF:

Recuerde que un adaptador hace dos interfaces existentes trabajan juntos en contraposición a la definición de uno completamente nuevo.

¿Quiere decir que el cambio de la interfaz existente para que pueda trabajar con otra interfaz es una implementación del adaptador ?

Update2:

Sólo encontraron esta increíble artículo: Illustrated GOF Design Patterns in C#

Este es verdadera estructura del golpeteo del puente:

me faltaba el hecho de que el patrón de puente le permite combinar las diferentes abstracciones e implementaciones y ampliar ellos de forma independiente

Answer 1

Creo que no tienes patrón de GoF puro aquí. Es algo entre Decorator y Adapter. Está cambiando la interfaz del cliente de servicio (adaptándola a sus necesidades). Pero también está agregando nuevas responsabilidades al cliente (registro y manejo de errores), eso es una parte decorativa. Si se queda con la interfaz de servicio original, sería Decorator puro.

ACTUALIZACIÓN: Cualquier uso de herencia no significa que estamos usando algún patrón GoF. Hay varias cosas que su arquitectura actual falta para ser Bridge:

• Jerarquía de implementaciones. Su interfaz de servicio debe definir algunas operaciones de bajo nivel. Y deberías tener varias implementaciones de servicios.
• La abstracción debe definir la interfaz de alto nivel. Por lo general, esas interfaces no se parecen a la interfaz de implementación (su interfaz de cliente es similar a la interfaz de servicio, existe en el mismo nivel de abstracción).
• Las implementaciones de abstracción deben usar la interfaz de servicio para implementar operaciones de alto nivel (es decir, no agregan algunas responsabilidades al servicio, implementan cosas diferentes, cosas de alto nivel).

Answer 2

Me explicaron el bridge patter n como una intención de combinar dos jerarquías de clase con diferentes propósitos. Por ejemplo, considere que está escribiendo un marco de ventana con diferentes tipos de controles y soporte para diferentes sistemas de ventanas. Tendría un árbol de clases para los controles y otro para abstraer las diferencias entre los sistemas de ventanas. Ahora, si desea agregar soporte para otro sistema de ventanas, simplemente agregue eso a ese lado de la jerarquía, y si desea agregar controles nuevos, los agrega a su lado. El "puente" existe entre las clases superiores de las dos jerarquías, donde su clase de control tiene acceso a las funciones abstractas definidas por la clase base de la jerarquía de clases que implementa el soporte para los diversos sistemas de ventanas.

Con el patrón de adaptador no desea combinar dos jerarquías de clases con diferentes intenciones, pero adapte una clase para que funcione con su propia interfaz. Supongo que si solo admitió un sistema de ventana única en el ejemplo anterior y no coloca una clase abstracta entremedias para mantener la extensibilidad, eso sería un adaptador en lugar de un puente.

Answer 3

Esto ha sido previamente discutido aquí - Difference between Bridge pattern and Adapter pattern - La cita real, que quiere de GoF es "adaptador hace que las cosas funcionan después de que están diseñados; Puente hace trabajar antes de que sean [GoF, P219]

.

su última pregunta consigue un sí - un adaptador se utiliza para hacer dos elementos de otra manera desagradables de una obra de teatro sistema muy bien juntos sin cambiar su funcionalidad fundamental allá posiblemente subconjuntos de la unión de sus funcionalidades -

un patrón de puente se utiliza generalmente para tratar con problemas en el diseño inicial donde el modelo mental presentado al consumidor podría ser wi Muy diferente del modelo que se da cuenta de la implementación del modelo de los consumidores. Considere una biblioteca matemática de alto rendimiento que tenga el mismo aspecto en una amplia variedad de procesadores; solo quiere multiplicar matrices, pero detrás de las escenas hay todo tipo de cruces que implican swizzling, flujos de datos paralelos, comportamientos extraños para evitar puestos en oleoductos y todo hecho de manera diferente en 3+ realizaciones de un núcleo de supercalibre de alto rendimiento, y eso es solo Intel :-(