• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Decorator Design Pattern

 
Anup Om
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
This is what I read about decorator design pattern.

Decorators prove more flexible than inheritance because the relationship between decorators and the objects they decorate can change at runtime, but relationships between base classes and their extensions are fixed at compile time.


Can someone please help me understand what it means by "relationship between decorators and the objects they decorate can change at runtime".

Thanks for your help in advance.
 
Adrabi Abderrahim
Greenhorn
Posts: 8
Eclipse IDE Fedora Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,

I tell you what I've understand from decorator pattern ,

decorator is like you buy a Playstation or any other thing, you can custom style by yourself (change at runtime), but you can't change into Playstation "base class", euh, in other word classes that decorate your object can be changed at runtime, example:

you've one class base 'X', and two classes for decoration 'Y', 'Z', and you've many possibilities to decorate 'X',


Z and Y is changeable in runtime, but X no,
 
Jan Cumps
Bartender
Posts: 2588
11
C++ Linux Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch, Adrabi.
 
Adrabi Abderrahim
Greenhorn
Posts: 8
Eclipse IDE Fedora Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you, dear Jan Cumps
 
Punit Jain
Ranch Hand
Posts: 1012
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
here you can fine most of design patterns with good examples:

http://javapapers.com/category/design-patterns/
 
Junilu Lacar
Bartender
Posts: 7480
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can see the Decorator pattern in action in the little icon beside a file or folder name in a GUI such as Windows Explorer or Finder in OS X. If you have installed a client extension for Subversion, for example, you will see the icon for files and folders "decorated" with some additional icon that indicates the state of that file or folder with regard to Subversion (new, modified, in conflict, not changed, etc.) This "decoration" can change at runtime as you perform actions on your files and folders. On my Mac, when I first create a file, its icon will be decorated with a little question mark to indicate that Subversion hasn't been told what to do with it yet. When I add the file or folder to Subversion, its icon will be decorated with a "+" sign to indicate that it has been added but not committed. And so on. That is to say, the "is a" relationship is temporal / can change over time and the relationship is conditional. In this example, "This file is a file that Subversion isn't tracking" is only true for a while, until you do something that makes this no longer true.

On the other hand, when you extend a class, the "is a" relationship between the parent and child classes is unconditional, lasts much longer, and cannot be changed at runtime.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic