Differences between Proxy and Decorator Pattern
Asked Answered
O

10

211

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?

Osteomyelitis answered 4/9, 2013 at 16:7 Comment(4)
Some links: Proxy and DecoratorHide
Where did you get the idea that Proxy uses composition and Decorator uses aggregation?Sagittate
@Sagittate see my comment for Rahul Tripathi answer.Recidivism
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.Haffner
S
101

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.
Surname answered 1/3, 2020 at 19:21 Comment(5)
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?Halliday
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.Surname
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.Stele
@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.Surname
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.Stele
S
154

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".

Stele answered 8/8, 2014 at 3:59 Comment(4)
"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.Paddie
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.Stele
What's the difference between "passed its delegatee" and "injected". Aren't they the same thing? It's like "new ColorWindow(plainWindow)".Arthurarthurian
@emeraldhieu, yes, passed and injected amount to the same thing. (Injection could happen after construction, if mutable.) The real distinction is that a Proxy might create its own privately, while a Decorator always takes it from an external source.Stele
S
109

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.

Spoiler answered 4/9, 2013 at 16:9 Comment(6)
A Proxy can still be used to add functionality though. Think of AOP proxies.Hide
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.Spoiler
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.Recidivism
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!!! :)Spoiler
It does you could add this line to your answer.Recidivism
Same question arised in my mind, hope discussion there will be relevant and helpful here as well... #36267190Astrict
S
101

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.
Surname answered 1/3, 2020 at 19:21 Comment(5)
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?Halliday
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.Surname
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.Stele
@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.Surname
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.Stele
U
61

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).

Utricle answered 23/10, 2013 at 13:51 Comment(0)
B
29

Sourcemaking article quotes the similarities and differences in excellent way.

  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

Regarding your queries, even Decorator also uses composition along with inheritance to dynamically add/remove additional functionalities to objects. The purpose and intent of these two patterns are different. jaco0646 post covers it thoroughly.

I call Proxy created with aggregation as Proxy and not decorator.

Related SE posts:

When to Use the Decorator Pattern?

Buyer answered 7/4, 2016 at 12:54 Comment(0)
C
6

Took a while to figure out this answer and what it really means. A few examples should make it more clear.

Proxy first:

public interface Authorization {
    String getToken();
} 

And :

// goes to the DB and gets a token for example
public class DBAuthorization implements Authorization {
    @Override
    public String getToken() {
        return "DB-Token";
    }
}

And there is a caller of this Authorization, a pretty dumb one:

class Caller {
    void authenticatedUserAction(Authorization authorization) {
        System.out.println("doing some action with : " + authorization.getToken());
    }
}

Nothing un-usual so far, right? Obtain a token from a certain service, use that token. Now comes one more requirement to the picture, add logging: meaning log the token every time. It's simple for this case, just create a Proxy:

public class LoggingDBAuthorization implements Authorization {

    private final DBAuthorization dbAuthorization = new DBAuthorization();

    @Override
    public String getToken() {
        String token = dbAuthorization.getToken();
        System.out.println("Got token : " + token);
        return token;
    }
}

How would we use that?

public static void main(String[] args) {
    LoggingDBAuthorization loggingDBAuthorization = new LoggingDBAuthorization();

    Caller caller = new Caller();
    caller.authenticatedUserAction(loggingDBAuthorization);
}

Notice that LoggingDBAuthorization holds an instance of DBAuthorization. Both LoggingDBAuthorization and DBAuthorization implement Authorization.

  • A proxy will hold some concrete implementation (DBAuthorization) of the base interface (Authorization). In other words a Proxy knows exactly what is being proxied.

Decorator:

It starts pretty much the same as Proxy, with an interface:

public interface JobSeeker {
    int interviewScore();
}

and an implementation of it:

class Newbie implements JobSeeker  {
    @Override
    public int interviewScore() {
        return 10;
    }
}

And now we want to add a more experienced candidate, that adds it's interview score plus the one from another JobSeeker:

@RequiredArgsConstructor 
public class TwoYearsInTheIndustry implements JobSeeker {

    private final JobSeeker jobSeeker;

    @Override
    public int interviewScore() {
        return jobSeeker.interviewScore() + 20;
    } 
}

Notice how I said that plus the one from another JobSeeker, not Newbie. A Decorator does not know exactly what it is decorating, it knows just the contract of that decorated instance (it knows about JobSeeker). Take note here that this is unlike a Proxy; that, in contrast, knows exactly what it is decorating.

You might question if there is actually any difference between the two design patterns in this case? What if we tried to write the Decorator as a Proxy?

public class TwoYearsInTheIndustry implements JobSeeker {

    private final Newbie newbie = new Newbie();

    @Override
    public int interviewScore() {
        return newbie.interviewScore() + 20;
    }
}

This is definitely an option and highlights how close these patterns are; they are still intended for different scenarios as explained in the other answers.

Congeneric answered 24/10, 2019 at 17:49 Comment(0)
O
5

Proxy and Decorator differ in purpose and where they focus on the internal implementation. Proxy is for using a remote, cross process, or cross-network object as if it were a local object. Decorator is for adding new behavior to the original interface.

While both patterns are similar in structure, the bulk of the complexity of Proxy lies in ensuring proper communications with the source object. Decorator, on the other hand, focuses on the implementation of the added behavior.

Oxide answered 7/2, 2018 at 2:5 Comment(2)
What are you saying that is different from the other 4 answers already here?Eggleston
I don't know if it's all there. I just felt the urge to chime in after reading the previous answers.Oxide
G
3

A Decorator adds extra responsibility to an object, while a proxy controls access to an object, they both use composition. If your wrapper class messes with the subject, it is obviously a proxy. Let me explain by a code example in PHP:

Code Example

Given is the following CarRepository:

interface CarRepositoryInterface 
{
    public function getById(int $id) : Car
}

class CarRepository implements CarRepositoryInterface 
{
    public function getById(int $id) : Car 
    {
        sleep(3); //... fake some heavy db call
        $car = new Car;
        $car->setId($id);
        $car->setName("Mercedes Benz");
        return $car;
    }
}

CarRepository-Proxy

A Proxy is often used as lazy loading or a cache proxy:

class CarRepositoryCacheProxy implements CarRepositoryInterface 
{
    private $carRepository;

    private function getSubject() : CarRepositoryInterface
    {
        if($this->carRepository == null) {
            $this->carRepository = new CarRepository();
        }
        return $this->carRepository;
    }
    
    /**
     * This method controls the access to the subject
     * based on if there is cache available 
     */
    public function getById(int $id) : Car
    {
        if($this->hasCache(__METHOD__)) {
            return unserialize($this->getCache(__METHOD__));
        }   
        $response = $this->getSubject()->getById($id);
        $this->writeCache(__METHOD__, serialize($response));
        return $response;
    }
    
    private function hasCache(string $key) : bool 
    {
        //... implementation 
    }
    
    private function getCache(string $key) : string 
    {
        //... implementation 
    }
    
    private function writeCache(string $key, string $result) : string 
    {
        //... implementation 
    }
}

CarRepository-Decorator

A Decorator can be used as long as the added behavior does not "control" the subject:

class CarRepositoryEventManagerDecorator implements CarRepositoryInterface 
{
    private $subject, $eventManager;

    /**
     * Subjects in decorators are often passed in the constructor, 
     * where a proxy often takes control over the invocation behavior 
     * somewhere else 
     */
    public function __construct(CarRepositoryInterface $subject, EventManager $eventManager)
    {
        $this->subject = $subject;
        $this->eventManager = $eventManager;
    }

    public function getById(int $id) : Car 
    {
        $this->eventManager->trigger("pre.getById");
        //this method takes no control over the subject
        $result = $this->subject->getById($id);
        $this->eventManager->trigger("post.getById");
        return $result;
    }
}
Gielgud answered 15/10, 2021 at 20:48 Comment(0)
C
0

Proxy provides the same interface to the wrapped object, Decorator provides it with an enhanced interface, and Proxy usually manages the life cycle of its service object on its own, whereas the composition of Decorators is always controlled by the client.

Chifforobe answered 14/11, 2019 at 8:22 Comment(0)
P
0

Let me explain the patterns first and then come to you questions.

From the class diagram and meanings, they are very similar:

  1. Both have the same interface as its delegatee has.
  2. Both add/enhance the behavior of its delegatee.
  3. Both ask the delegatee to perform operations(Should not work with null delegatee).

But they have some difference:

  1. Different intents: Proxy enhances the behavior of delegatee(passed object) with quite different domain knowledge from its delegatee. Eg, a security proxy adds security control of the delegatee. A proxy to send remote message needs to serialize/deserialize data and has knowlege on network interfacing, but has nothing to do with how to prepare source data. Decorator helps on the same problem domain the delegatee works on. Eg, BufferedInputStreaman(an IO decorator) works on input, which is the same problem domain(IO) as its delegatee, but it cannot perform without a delegatee which provides IO data.

  2. Dependency is strong or not: Decorator relies on delegate to finish the behavior, and it cannot finish the behavior without delegatee(Strong). Thus we always use aggration over composition. Proxy can perform faked behavior even it does not need a delegatee(Weak). Eg, mockito(unit test framework) could mock/spy a behavior just with its interface. Thus we use composition to indicate there's no strong dependency on real object.

  3. Enhance multipletimes(as mentioned in question): Proxy: we could utilize proxy to wrap real object once not several times. Decorator: A decorator can wrap the real object several times or can wrap the object which is already wrapped by a decorator(which could be both a different decorator or the same decorator). Eg, for an order system, you can do discount with decorators. PercentageDiscountDecorator is to cut 50% off, and DeductionAmountDiscountDecorator is to deduct 5$ directly if the amount is greater than 10$(). So, 1). When you want to cut 50% off and deduct 5$, you can do: new DeductionAmountDiscountDecorator(new PercentageDiscountDecorator(delegatee)) 2). When you want to deduct 10$, you can do new DeductionAmountDiscountDecorator(new DeductionAmountDiscountDecorator(delegatee)).

The answer to the question has nothing to do with the difference between Proxy and Decorator. Why?

  1. Design patterns just patterns for people who are not good at OO skills to make use of OO solutions. If you are familiar with OO, you don't need to know how many design patterns there(Before design patterns invented, with the same prolbem skilled people could figure out the same solution).
  2. No two leaves are exactly the same, so as the problems you encount. People will always find their problems are different from the problems given by design patterns.

If your specified problem is really different from both problems that Proxy and Decorator work on, and really needs an aggregation, why not to use? I think to apply OO to your problem is much more important than you label it a Proxy or Decorator.

Patterman answered 9/10, 2021 at 9:8 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.