The relationship between decorator and target (in the code example between Troll und SmartTroll) ist not a composition as described in the code comment lines of class App. It's a aggregation. In a composition both instances canncot live without the other one. But the target (Troll) could live without the decorator (Smart Troll). Changed "composition" to "aggregation" in the comment lines. Code lines are unchanged. Greetings Thomas
layout, title, folder, permalink, pumlid, categories, tags
layout | title | folder | permalink | pumlid | categories | tags | |||
---|---|---|---|---|---|---|---|---|---|
pattern | Decorator | decorator | /patterns/decorator/ | HSV14SCm20J0Lk82BFxf1YF6LaP26ZZizfDVVhjRC-bPDRs_Bc35cyZvAMV3bKU6kao36ehCGQtdms2d3z-yLursshuOKBUWmV43LPNfZEcaaFzA-YWhH_y2 | Structural |
|
Also known as
Wrapper
Intent
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
Applicability
Use Decorator
- to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects
- for responsibilities that can be withdrawn
- when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing
Real world examples
- java.io.InputStream, java.io.OutputStream, java.io.Reader and java.io.Writer
- java.util.Collections#synchronizedXXX()
- java.util.Collections#unmodifiableXXX()
- java.util.Collections#checkedXXX()