2011-06-11 13 views
5

Mientras estudiaba el código fuente de Neo4J noté que usan un patrón muy interesante para desacoplar la interfaz de la implementación. Hay una interfaz Node implementada solo por la clase NodeProxy. NodeProxy a su vez delega en NodeImpl, lo que podría pensar que implementa Node también, pero no es así. NodeImpl tiene los mismos métodos con la misma firma y es la implementación de respaldo de Node, pero no implementa Node. He utilizado el patrón de proxy antes, pero habría hecho NodeImpl para implementar Node como lo hace NodeProxy. ¿Alguna idea sobre las ventajas que brinda este patrón?Patrón de API interesante

Edit 1: Gracias al comentario de Cirkel ahora sé que se llama Bridge pattern y el objetivo principal es "desacoplar una abstracción de su implementación para que los dos puedan variar de forma independiente", interesante.

+0

¿Cómo delega 'NodeProxy' a' NodeImpl'? 'NodeProxy' no usa' NodeImpl' de ninguna manera. Es al revés: 'NodeImpl' usa' NodeProxy'. –

+0

No estoy seguro de cuáles son los beneficios porque no sé absolutamente nada sobre el marco que está mirando, pero suena como que NodeProxy actúa como un localizador de servicios. –

+1

Se llama _Bridge pattern_ –

Respuesta

1

El resultado es que te obliga a pasar por NodeProxy en lugar de trabajar directamente con NodeImpl. No estoy lo suficientemente familiarizado con Neo4J para decir por qué sería ventajoso hacerlo en ese contexto. Tal vez NodeProxy está equipado con comportamientos adicionales que NodeImpl no tiene.

0

El efecto principal de esta implementación sería que las dependencias se revierten. Si permites que NodeImpl implemente Node, entonces NodeImpl dependería de Node. Al introducir NodeProxy, deja que NodePoxy dependa de NodeImpl, mientras que NodeImpl no depende de nada. Esto podría ser una ventaja o una necesidad por alguna razón en un contexto específico.

+0

Claro, pero NodeProxy también depende del Nodo, así que en lugar de tener un objeto dependiente de Node, ahora tenemos un Objeto dependiente de NodeImpl y Node y uno dependiente de Node: es difícil ver la ventaja, pero probablemente tengan que funcionar algunos extrañas limitaciones/requisitos que no conocemos – Voo

2

Si mira NodeImpl un poco más detallada, verá que los métodos correspondientes a los métodos Node tienen firmas diferentes; también toman un argumento NodeManager.

Esto solo hace que sea imposible para ellos implementar la interfaz de nodo.

El NodeProxy mantiene una referencia a un NodeManager, que luego puede pasar a los objetos NodeImpl.

Cuestiones relacionadas