In a traditional GoF Proxy, you have an Interface, an Implementation, that implements the Interface, and a Proxy that also implements the Interface, references an instance of Implementation, and delegates the calls on the Interface methods to the same methods in the Implementation instance.

Say you would call the Interface/Implementation pair a "Fragment", and you would have several different such pairs. Now imagine you create a Whole Interface that implemented all those Fragment interfaces, and a single Whole Proxy that implemented the Whole Interface, and delegated to the appropriate Fragment Implementation instance.

Is this pattern at all (since Patterns must be common solution to common problems)? And if so, as it got a name? Or could it be cleanly defined as a combination of patterns?

Being able to clearly describe how this code works in terms of patterns would make it much easier to explain to others how create compatible code, and help to find a framework that already implements this pattern.

A Proxy normally delegates to a single instance.

A Facade normally offers a different interface to that multiple objects it hides.

A Bridge also offers a different interface to that the single instance it hides.

A Composite expects all components to share the same base interface.

A Decorator extends the interface of the wrapped object, like here, but normally implements the additional functionality itself, instead of delegating to another objects.

A Whole that implements a single Fragment is just a Proxy pattern, but a Whole that extends another Whole is closest to a Decorator pattern.

There are several reasons to do it this way. Firstly, client code should see WholeB as extending WholeA, although the implementer of FragmentB cannot extend FragmentA (which was implemented by someone else). Secondly, references to WholeX (ProxyX) stay valid, even if implementation of FragmentX is replaced a runtime. Thirdly, both ProxyB and ProxyC can share the same instance of FragmentAImpl.

3 Answers
3

It offers a single port of call for clients needing the services of several interfaces. This is a facade. The fact that normally a facade declares a specific interface instead of re-using the ones from the classes/objects it aggregates is, to me, an implementation detail.

Update

From the GoF book:

Intent: Provide a unified interface to a set of interfaces in a
subsystem. Facade defines a higher-level interface that makes the
subsystems easier to use.

Especially when you then read

Motivation: Structuring a system into sybsystems helps reduce
complexity. A common design goal it to minimize the communication and
dependencies between subsysems. One way to achieve this goal is to
introduce a facade object that provides a single, simplified
interface to the more general facilities of a subsystem.

While the comment by @pdr would seem correct, I would argue differently.

The "simplified" interface can most certainly be the same as the interfaces put behind the facade. Its just a question of how simple those "facaded" interfaces are.

Plus, I don't take "simplifies" as a requirement for an object to be a facade.

The motivation to minimize communication and dependencies between subsystems is far more important and the main goal of the facade pattern. A facade object providing a single point of access to multiple (unchanged interfaces of) subsystems, still fulfills this goal regardless of whether it (also) simplifies the interface(s) offered by the subsystems it hides.

Short, concise, correct and not confusing. The better answer to this question.
–
FalconSep 17 '11 at 12:19

1

This is incorrect. A Facade is a simplification of an interface; it can't be the same.
–
pdrSep 17 '11 at 16:07

1

@pdr I do not agree, see update to answer.
–
Marjan VenemaSep 17 '11 at 17:03

I'm still not seeing how any part of that motivation is achieved here. In fact, now that I read the final paragraph again, particularly the last sentence, I am convinced that the OPs motivation matches more closely the Proxy pattern. But I still maintain we don't have enough information to give it a name.
–
pdrSep 17 '11 at 18:34

@pdr I can see why you see it as a Proxy. However, the motivation for a Proxy is for example to delay resource or otherwise expensive initialization/instantiation of the object behind the proxy until it is actually needed. The motivation of the poster seems to be to hide away multiple instances behind a single ..., well, facade (sorry couldn't resist), so that object serves as a decoupling point between what is in front and behind of it. If you have a copy of the GoF book, the picture in the Facade discussion makes that much clearer than I seem able to convey.
–
Marjan VenemaSep 17 '11 at 19:24

Anyhow, there's no reason to dogmatically stick to the exact same patterns in GoF.
That book should expand your professional vocabulary and maybe even teach you some good ideas, but it's not the programmer's ten commandments.

I couldn't see a reason for you here to actually use the Proxy pattern, theoretically.

Having a separated interface/implementation is very good, but that doesn't mean it has to act as a proxy. If you want a name for it, just label it as "loosely coupled".

You can call it any name that makes sense. You don't have to try to dig up a standard name when it's not totally obvious.

In general, I find that the whole dogmatic way of creating clean code is sometimes deviant from the original purpose - to create code that's easy to read and understand.

If you can't find a completely standard name for what you're doing, don't try to turn it into an existing pattern or name. That only confuses fellow programmers.

Just give it a new one that makes sense to you and your fellow programmers. Consult, together, in your workplace - where it matters.

I don't think Mediator is correct either, because it's goal is to "prevent" the different objects implementing the behavior to "know each other". But in my proposed design, I don't want to prevent FragmentB of knowing FragmentA, I just want to enable FragmentB to exist without knowing the concrete implementation of FragmentA.
–
Sebastien DiotSep 17 '11 at 11:45

1

And while I agree with your answer (+1), I'll go with Marjan. A Facade doesn't stop being a Facade because it expose the same interface as the objects it delegates to.
–
Sebastien DiotSep 17 '11 at 11:50

You're abusing design patterns here. Like I said, you're looking for loose-coupling, not proxies. Proxies are generally used to present a lighter interface to large complex objects, or to access remote objects, etc. I think it's a bad idea to use a pattern here. Like I said, you only want loose-coupling, and that's a very basic term.
–
Yam MarcovicSep 17 '11 at 12:15

Don't try to separate design patterns by their implementation details. Doing so will cause great confusion when you come to Strategy and State, or cause you to overcomplicate things to avoid having arguments on the Execute method of a Command.

Separate design patterns by their intent. To take your five examples:

A Proxy is a class which creates an interface to something expensive, which is not eaily duplicated, like a network connection or a large chunk of memory. * see comments

A Facade is a simplification of an overcomplicated API. Reducing the surface area, as they say; making it simpler to use.

A Bridge is where an abstraction is decoupled from the implementation, so that when the implementation changes, the calling code doesn't have to. Initially, the interface doesn't have to be different, as you suggested, you just can't insist on them remaining the same.

A Composite is for taking multiple objects and wrapping them in a single abstraction.

A Decorator allows objects to get wrapped in objects with the same interface, so that they add functionality without changing the calling code.

It's hard to tell from your example which you are trying to implement, because you've described the implementation and not the intent. But I'm guessing that the Proxy pattern is appropriate.

In my understanding a proxy needn't necessarily wrap something expensive. A proxy is just an interface to control access to another object. Often times this pattern is used to provide lazy loading behaviour or for interception purposes. A facade is pretty similar, it is usually used to provide a simpler interface, but it can also be used to provide an interface to multiple classes.
–
FalconSep 17 '11 at 20:01

I should add: The proxy shares the interface of the single class it wraps.
–
FalconSep 17 '11 at 20:11

@Falcon: The point of the Proxy is to have a heavyweight object which can be instantiated by a lightweight object when needed and kept around if its likely to be needed again. This way, the heavyweight object only needs to know how it operates and the client only needs to know that it wants the object, the Proxy's sole responsibility is really to decide when to do what for efficiency.
–
pdrSep 17 '11 at 20:45

1

I really don't agree. The point of the proxy is to control access to another object and nothing else. If the object is heavyweight or not is totally irrelevant. What about AOP proxies for example? They're often used to provide simple logging mechanisms or to control access privileges? They statisfy the requirements for a proxy and do not involve heavy objects.
–
FalconSep 17 '11 at 20:49

@Falcon: Googling around, I can see your point. I'm still not entirely convinced this was the original intent and this would explain why four different names have grown for different types of Proxy. The one I'm referring to being the Virtual Proxy. But ok, I stand corrected.
–
pdrSep 17 '11 at 21:12