aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Removing Decorator From The Decorated Object Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Removing Decorator From The Decorated Object" Watch "Removing Decorator From The Decorated Object" New topic
Author

Removing Decorator From The Decorated Object

Thennam Pandian
Ranch Hand

Joined: Oct 11, 2005
Posts: 163
I am reading HeadFirst Design pattern book. In the book they have explained the decorator pattern with "coffee" menu.

Consider the following scenario :

1. Customer has added Expresso with mocha and soy.

2. Now the Expresso is decorated with mocha and soy.

3. Suddenly the customer want to replace soy with Whip.

In this case, we need to remove the soy from the decorated object and decorate with Whip.

Is it possible to remove decorator from the decorated Object? if yes, please explain.

or

decorator talks about only adding dynamic responsibility to the component ?
Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

You could "remove" the decorator by providing a getter for the decorated object and continuing with that reference and discarding the decorator reference.


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
Thennam Pandian
Ranch Hand

Joined: Oct 11, 2005
Posts: 163
Thanks for your reply.

I have tried the following and it is working fine.

I have provided one method called "getPrevBeverage" in CondimentDecorator.

This method will return the decorated object before adding the current decorator object.

With this implementation, am able to solve the above problem.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1666
    
    7

Adding a getter to retrieve a previous decorator doesn't actually make a whole lot of sense to me.
Consider that the intent of a decorator is to add behaviour dynamically to an instance of some type (class or interface), and that instance can be decorated multiple times. How are you ever supposed to know which decorator reference - or indeed a reference to the original undecorated instance - will be returned. It's completely dependent on the order in which the decorators were applied. Further more, if you are strictly programming to an interface, all you'll have available to you is the interface of the orginal undecorated type. Which would need to specify a getter that returns an instance of itself, soley for the purpose of obtaining a previous decorator reference - something it shouldn't have any knowledge about in the first place. This seems odd to me. Come to think of it, I don't think I've ever encountered a decorator implementation that allowed for this kind of unwrapping behaviour, and I'm struggling to come up with a use case for it.

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18124
    
    8

Jelle Klap wrote:I don't think I've ever encountered a decorator implementation that allowed for this kind of unwrapping behaviour, and I'm struggling to come up with a use case for it.


My approach would be to just keep a reference to the original object. Don't make the decorator return a reference to the decoratee (the thing being decorated), just keep your own reference to it.

It's also worth mentioning that in real life it's often a bad idea to work with the undecorated object, but in this case this is just one of those silly contrived examples.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1666
    
    7

Paul Clapham wrote:
Jelle Klap wrote:I don't think I've ever encountered a decorator implementation that allowed for this kind of unwrapping behaviour, and I'm struggling to come up with a use case for it.


My approach would be to just keep a reference to the original object. Don't make the decorator return a reference to the decoratee (the thing being decorated), just keep your own reference to it.

It's also worth mentioning that in real life it's often a bad idea to work with the undecorated object, but in this case this is just one of those silly contrived examples.


Exactly, just retain a reference to the original.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Removing Decorator From The Decorated Object
 
Similar Threads
Building a Decorator Question
This is going to be long... But appreciate all help i can get...
Decorator Pattern.
Question about HF Design Patterns book
HeadFirst Design Patterns - Decorator Chapter