If In Proxy Pattern we have interface instead of actual concrete Subject in Proxy class is it equivalent to Decorator Pattern

Question

Proxy pattern delegates the request to the Real subject after doing some additional processing like applying checks if request needs to be processed or not based on may be some credential checks.

It has class diagram as below

Proxy class has a direct reference to the concrete Subject.

Decorator Pattern enriches the behavior of the component [like proxy it also does some additional processing and delegates the operation to the real component]. The class diagram of this pattern is similar to Proxy pattern with only difference being it has the reference to the interface of the component.

Having concrete real subject in Proxy class makes it difficult for unit testing as Classes should only be dependent upon interfaces and not the implementations. My Question is if Proxy pattern also has the reference to the interface exposed by the Real subject then will it be equivalent to the Decorator pattern. In such a case the class diagram of the proxy pattern will also become as below

Montpellier

Both have different purposes. Check this question : #350904 – Herculean

One could say that proxy is a (restricted) special case of a decorator. – Osrick

Answer 1

It's all about the intent. Functionally, they will be equivalent, but the point of decorator is to add features to an object dynamically, while proxy just controls the access to the target object without adding any additional features to it.

So the client of the proxy expects the same outcome as if it worked with the real object, while the client of the decorator leaves it to the decorator to execute any additional logic before and/or after delegating the call to the target.

So, conceptually it seems that in your example you're still dealing with a proxy.

Thea

thanks for the reply, it indeed adds clarity in my understanding but still there is little doubt. Proxy also in a way adds features like it may check for user credentials and if valid will delegate the request to subject, in a way it is adding a work on top of what subject does, Does proxy differs as it restricts the operation execution if validation fails where as decorator does not restricts but always enriches the behavior of the subject. – Montpellier

"Proxy also in a way adds features like it may check for user credentials and if valid will delegate the request to subject, in a way it is adding a work on top of what subject does," There is some additional code involved in both cases of course (after all, both exist to actually execute something meaningful). – Thea

"Does proxy differs as it restricts the operation execution if validation fails where as decorator does not restricts but always enriches the behavior of the subject." Indeed, that is usually a good indicator (if there is nothing to decorate, why call it decorator?), but there are always exceptions that prove the rule. – Thea

Design patterns exist to be combined. You can't build anything with a single pattern. Very often the from-the-book patterns are modified to suit the actual requirements (and they are meant to be changed and accommodated, actual structure of patterns in the books are more like some basic guidelines and examples). For example, the AOP proxies (transactional methods are famous examples). They always delegate to the target, they decorate the method with transactional boundaries, etc., but nevertheless the terms proxy and interceptor were accepted by the industry/community. – Thea

thanks for the nice reply and the comments... I have accepted your answer and I would like you to add the comments (the last one) in your answer, it is indeed good and very helpful. I now understand that patterns should be looked form the problem point of view and not from the solution point of view. We have a problem , we apply good OO practices and principles and the solution will be one of the patterns. Patterns just help us in thinking in a direction, but focus should be solving the problem and not enforcing a pattern. – Montpellier

Answer 2

Yes. If you look at structure, it will be same for both Decorator and Proxy. Only intent is different.

Decorator:

1. Add behaviour to object at run time. Inheritance is the key to achieve this functionality, which is both advantage and disadvantage of this pattern.
2. It modifies the behaviour of interface.

e.g. (with chaining ) : java.io package classes related to InputStream & OutputStream interfaces

FileOutputStream fos1 = new FileOutputStream("data1.txt");  
ObjectOutputStream out1 = new ObjectOutputStream(fos1);

Consequences

1. Decoration is more convenient for adding functionalities to objects instead of entire classes at runtime. With decoration it is also possible to remove the added functionalities dynamically.
2. Decoration adds functionality to objects at runtime which would make debugging system functionality harder.

Proxy:

1. Use it for lazy initialization, performance improvement by caching the object and controlling access to the client/caller. It may provide alternative behaviour or call real object. During this process, it may create new Object.
2. Unlike Decorator, which allows chaining of objects, Proxy does not allow chaining.

e.g.: java.rmi package classes

Key takeaways:

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.

Useful links:

Decorator_pattern from wikiepdia

decorator from sourcemaking

decorator-pattern from oodesign

Proxy_pattern from wikipedia

proxy from sourcemaking

proxy-pattern from oodesign

Herculean