Please enable JavaScript.
Coggle requires JavaScript to display documents.
Decorator (Consequences (Avoids feature-laden classes high up in the…
Decorator
Consequences
Avoids feature-laden classes high up in the hierarchy - need not have a super class that plans for all foreseeable features. Can instead add smaller classes
-
-
Lots of little objects lots of little objects that do similar things, might be apparent to creator but not for others
NOTE This pattern can be identified if methods and constructors accept instance of same abstract class or interface
Applicability
-
-
When we want to add functionality transparently and dynamically to a few objects without adding them to others
-
Key Objects
-
Decorator - maintains a reference to the component and defines an interface that conforms to the components interface
-
-
Implementation
Omitting the abstract Decorator class If only one responsibility is added, don't need the decorator abstract class
Keeping Component classes lightweight The abstract component class should focus on defining the interface and not storing data. Doing latter will make the decorators heavyweight
Implementation Conformance a decorator's interface must conform to the interface of the component it decorates
Changing the skin of an object versus changing its guts - decorator is changing skin. If we change guts, use strategy pattern instead
Motivation
Inheritance is static and adds functionality at compile time. If we want to add functionality at run time to objects as well as the entire class, can use Decorator pattern
In this case, the decorator or wrapper holds an instance of the class that is decorating and it can add specific functionality as required
Intent
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
-
-