• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

decorator pattern from HFDP

 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Has any body read decorator pattern from HFDP. I am confuse with their very first example.

Beverage class has a field description, a method getDescription() and an abstract method cost()...

All sub classes will implement cost() as per they want. But I am confuse with description field. How sub classes will use this description and getDescription()...

Please help.
Thanks.
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I havent understood your question .

When the subclass extends Beverage the subclasses will have the method getDescription in them.
 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Pradip Bhat:
I havent understood your question .

When the subclass extends Beverage the subclasses will have the method getDescription in them.


Yes.

But when we will call this getDescription() method from super class reference that is referring to sub class object (I am sure, we will do it like this only) then it will print description of super class (not the description of individual sub classes).

Like this:



I hope, now my point is clear.
Please comments.
Thanks a lot.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A common idiom is to provide the value for a field in the constructor, so that different subclasses can initialize it differently. Not sure wether the HF example does this, though.
 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


oops... I missed it. We can always override method in sub class if we want some different description.




A common idiom is to provide the value for a field in the constructor, so that different subclasses can initialize it differently. Not sure wether the HF example does this, though.


Yes, got it.

Thanks Pradip and Ilja
 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
...But they have not overridden the getDescription() method in sub classes.

Thanks.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How is the description initialized in the base class?
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
 
ankur rathi
Ranch Hand
Posts: 3830
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
How is the description initialized in the base class?


Actually, they have not given the code. But I think, initilizing at the time of declaration is the only option...

 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I tried to say above, there *is* another option, one that gives subclasses the ability to specificy an individual description:

 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I thought this was aobut the decorator pattern though?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mr. C Lamont Gilbert:
I thought this was aobut the decorator pattern though?


Yes. Super, in this context, is the abstract base class for all Decorator implementations, the way I understand it.
 
Vladas Razas
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

...But they have not overridden the getDescription() method in sub classes.


They did. Page 95 super of all beverages Beverage returns default value "Unknown Beverage". Page 97 derrived Mocha overrides getDescription() :

 
Thomas Andersson
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They have set the description attribute in the subclass constructor (only done for the "base" ingridient).



This could of course also be done by making the description attribute private and adding a constructor that takes a string, as mentioned above. The solution with the added constructor is perhaps cleaner.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Thomas Andersson:
They have set the description attribute in the subclass constructor (only done for the "base" ingridient).



This could of course also be done by making the description attribute private and adding a constructor that takes a string, as mentioned above. The solution with the added constructor is perhaps cleaner.


Definitely!
 
Shafique Razzaque
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My input on this topic:

The reason description method has an implmentation in the base class (Beverage) is becoz: all the Concrete Components (Expresso, HouseBlend etc) need not override it. Description is a simple method all ConcreteComponents may simply inherit and reuse without any change.

However the example shows us to decorate the description and cost(in ConcreteDecorators). So, to enforce the ConcreteDecorators to implement their own getDescription method..it is made abstract in the Decorator interface (CondimentDecorator).

As for the getCost method, it needs to be overriden at all ConcreteComponents and decorated at the ConcreteDecorators. Hence it is made abstract at the base class itself (at Beverage).

Hope it clarifies your doubt.

Cheers,
Shafique Razzaque,
Singapore.
 
Ner min
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi

# Shafique i agree with u

BUT i think this is unnecessary done to complicated.
imo, there is no need for implementation of getDescription() in Beverage
and then make it abstract in CondimentDecorator.
For what is the description with the value of �Unknown Beverage� for?
Insteed why not just make getDescription() abstract inside Beverage
and omit it from CondimentDecorator?
That way u will still enforce the ConcreteDecorators to implement getDescription() BUT it is MUCH MORE SIMPLE.

Any drawbacks to this?
 
Shafique Razzaque
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In reply to Ner min's comment:

The only drawback would be:
Every Concrete Component will also have to write the getDescription() method.
 
Ner min
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
???
but i thought the whole Idea is to force every ConcreteComponent to write the getDescription() implementation.
That's what for r Decorators for: they add extensons by reimplementing.
Again:
For what is the description with the value of �Unknown Beverage� for?

Imagine that someone ask u:
1:Hi Mr. would u like a niche fresh Unknown Beverage?
2 h hm...
1:with suger?
[ October 27, 2005: Message edited by: Ner min ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic