Interesting API pattern

While studying the Neo4J source code I noticed that they use a very interesting pattern for decoupling interface from implementation. There is a Node interface that is implemented only by the NodeProxy class. NodeProxy in turn delegates to NodeImpl which you would think that implements Node too, but it doesn´t. NodeImpl has the same methods with the same signature and is the backing implementation of Node, but it doesn't impl开发者_如何学Cement Node. I have used the proxy pattern before but would have made NodeImpl to implement Node as NodeProxy does. Any ideas about the advantages this pattern brings?

Edit 1: Thanks to Cirkel's comment I now know that is called Bridge pattern and the main objective is to "decouple an abstraction from its implementation so that the two can vary independently", interesting.

If you look at NodeImpl a bit more detailed, you see that the methods there corresponding to the Node methods have different signatures - they additionally take a NodeManager argument.

This alone makes it impossible for them to implement the Node interface.

The NodeProxy then maintains a reference to a NodeManager, which it then can pass to the NodeImpl objects.

The net of it is that it forces you to go through NodeProxy rather than working with NodeImpl directly. I'm not familiar enough with Neo4J to say why it would advantageous to do it in that context. Perhaps NodeProxy is instrumented with additional behaviors that NodeImpl doesn't have.

The main effect of this implementation would be that the dependencies are reverted. If you let NodeImpl implement Node, then NodeImpl would depend on Node. By introducing NodeProxy you let NodePoxy depend on NodeImpl while NodeImpl does not depend on anything. This could possibly be an advantage or neccesary for some reason in a specific context.