Differences between Proxy and Decorator Pattern

Question

Can you give any good explanation what is the difference between Proxy and Decorator?

The main difference I see is that when we assume that Proxy uses composition and Decorator uses aggregation then it seems to be clear that by using multiple (one or more) Decorators you can modify/ add functionalities to pre-existing instance (decorate), whereas Proxy has own inner instance of proxied class and delegates to it adding some additional features (proxy behaviour).

The question is - Does Proxy created with aggregation is still Proxy or rather Decorator? Is it allowed (by definition in GoF patterns) to create Proxy with aggregation?

Solution 1

Here is the direct quote from the GoF (page 216).

Although decorators can have similar implementations as proxies, decorators have a different purpose. A decorator adds one or more responsibilities to an object, whereas a proxy controls access to an object.

Proxies vary in the degree to which they are implemented like a decorator. A protection proxy might be implemented exactly like a decorator. On the other hand, a remote proxy will not contain a direct reference to its real subject but only an indirect reference, such as "host ID and local address on host." A virtual proxy will start off with an indirect reference such as a file name but will eventually obtain and use a direct reference.

Popular answers indicate that a Proxy knows the concrete type of its delegate. From this quote we can see that is not always true.

The difference between Proxy and Decorator according to the GoF is that Proxy restricts the client. Decorator does not. Proxy may restrict what a client does by controlling access to functionality; or it may restrict what a client knows by performing actions that are invisible and unknown to the client. Decorator does the opposite: it enhances what its delegate does in a way that is visible to clients.

We might say that Proxy is a black box while Decorator is a white box.

The composition relationship between wrapper and delegate is the wrong relationship to focus on when contrasting Proxy with Decorator, because composition is the feature these two patterns have in common. The relationship between wrapper and client is what differentiates these two patterns.

• Decorator informs and empowers its client.
• Proxy restricts and disempowers its client.

Solution 2

The real difference is not ownership (composition versus aggregation), but rather type-information.

A Decorator is always passed its delegatee. A Proxy might create it himself, or he might have it injected.

But a Proxy always knows the (more) specific type of the delegatee. In other words, the Proxy and its delegatee will have the same base type, but the Proxy points to some derived type. A Decorator points to its own base type. Thus, the difference is in compile-time information about the type of the delegatee.

In a dynamic language, if the delegatee is injected and happens to have the same interface, then there is no difference.

The answer to your question is "Yes".

Solution 3

Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object.

EDIT:-

Relationship between a Proxy and the real subject is typically set at compile time, Proxy instantiates it in some way, whereas Decorator is assigned to the subject at runtime, knowing only subject's interface.

Solution 4

Decorator get reference for decorated object (usually through constructor) while Proxy responsible to do that by himself.

Proxy may not instantiate wrapping object at all (like this do ORMs to prevent unnecessary access to DB if object fields/getters are not used) while Decorator always hold link to actual wrapped instance.

Proxy usually used by frameworks to add security or caching/lazing and constructed by framework (not by regular developer itself).

Decorator usually used to add new behavior to old or legacy classes by developer itself based on interface rather then actual class (so it work on wide range of interface instances, Proxy is around concrete class).

Solution 5

Key differences:

1. Proxy provides the same interface. Decorator provides an enhanced interface.
2. Decorator and Proxy have different purposes but similar structures. Both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward requests.
3. Decorator can be viewed as a degenerate Composite with only one component. However, a Decorator adds additional responsibilities - it isn't intended for object aggregation.
4. Decorator supports recursive composition
5. The Decorator class declares a composition relationship to the LCD (Lowest Class Denominator) interface, and this data member is initialized in its constructor.
6. Use Proxy for lazy initialization, performance improvement by caching the object and controlling access to the client/caller

Sourcemaking article quotes the similarities and differences in excellent way.

Related SE questions/links:

When to Use the Decorator Pattern?

What is the exact difference between Adapter and Proxy patterns?

View more solutions

Comments

[Sotirios Delimanolis]

Some links: Proxy and Decorator

[CPerkins]

Where did you get the idea that Proxy uses composition and Decorator uses aggregation?

[Łukasz Rzeszotarski]

@CPerkins see my comment for Rahul Tripathi answer.

[hyankov]

And also decorator (patterns.cs.up.ac.za/examples/ch2/decorator-theory.cs) - obviously aggregation, proxy (patterns.cs.up.ac.za/examples/ch2/proxy-theory.cs) - obviously composition.

[Sotirios Delimanolis]

A Proxy can still be used to add functionality though. Think of AOP proxies.

[Rahul Tripathi]

Fully agree Sir. I would convert that in other words what I meant was with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of abject inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.

[Łukasz Rzeszotarski]

In this case when the instance is 'hidden' in the proxy the diference is clear for me (as I wrote) however I think that often people call as proxy classes which take the proxied object which was passed as constructor parameter. In this case the difference of adding new functionality or controlling is (very) thin for me.

[Rahul Tripathi]

Relationship between a Proxy and the real subject is typically set at compile time, Proxy instantiates it in some way, whereas Decorator or Adapter are assigned to the subject at runtime, knowing only subject's interface. Hope that makes sense!!! :)

[Łukasz Rzeszotarski]

It does you could add this line to your answer.

[Alexey]

"But a Proxy always knows the (more) specific type of the delegatee. " I don't think it's true. Imagine remote proxy. Proxying mechanism don't need to know any specifics of the remote object. The remote system registers the object with the specified interface. And local proxy exposes the same interface.

[cdunn2001]

I took a class on this at Amazon from a visiting lecturer who knew his stuff. There is a difference between the use of a "proxy" executable (e.g. with a web service) and the Proxy Design Pattern. The UMLs of the Proxy pattern and of the Decorator pattern can be different. But nothing prevents a Proxy from having the same API as its delegatee. Decorator is a strict subset of Proxy, but a Decorator might still be called a Proxy depending on whether the underlying API is guaranteed to be the same.

[nits.kk]

Same question arised in my mind, hope discussion there will be relevant and helpful here as well... stackoverflow.com/questions/36266690/…

[Stephen Rauch]

What are you saying that is different from the other 4 answers already here?

[James Lin]

I don't know if it's all there. I just felt the urge to chime in after reading the previous answers.

[Sebastian Nielsen]

In the case that (e.g. a guard-access) proxy is implemented exactly like a decorator, is the reason for the distinction between them then solely to convey the intent: to constrain access or augment behavior?

[jaco0646]

According to the GoF, yes. They often emphasize intent when distinguishing between patterns. I would add that a client is less likely to be aware of a proxy than a decorator, meaning who instantiates it is an important difference.

[cdunn2001]

And what if it's a mixture? What if the wrapper both increases and restricts its client? That's the problem with concentrating on intent. This is still a good answer, and it seems to be what GoF had in mind. But it's easy to mis-diagnose the intent, or simply to disagree subjectively. In most cases, looking at the wrapper's implementation is enough.

[jaco0646]

@cdunn2001, I don't necessarily disagree in principle; but for the sake of argument: if the wrapper is a mixture, it likely violates the Single Responsibility Principle. If its intent is easily misdiagnosed, then it does not adequately convey intent; and a strong argument can be made that the primary difference between "good" code and "bad" code is that good code conveys intent where bad code does not. In either case, the wrapper has bigger problems than identifying a design pattern.

[cdunn2001]

I just noticed a "deleted" answer, which was plagiarized from powerdream5.wordpress.com/2007/11/17/… It's still a good link. That UML shows the distinction. I'm saying that if the delegatee has a more specific type than the base type of the wrapper, then the wrapper is not a decorator. Intent is still invaluable knowledge though. I don't think we disagree.