Decorator pattern

The decorator pattern is an object structural pattern that dynamically adds some additional responsibilities to an object. The decorator pattern is more flexible than subclassing in terms of added functionality.

motivation

Sometimes it is necessary to add some functions to an object instead of the entire class. It is also possible to use inheritance, but the subclass behavior is static and the user cannot dynamically control it; if you want to add additional behavior to the object at runtime without modifying the code , you can use the decorator pattern

scenes to be used

• Dynamically and transparently add responsibilities to individual objects without affecting other objects
• Deal with responsibilities that can be revoked
• When the method of generating subclasses cannot be used for expansion, there are two cases
  • There may be a large number of independent extensions, and a large number of subclasses will be generated to support each combination, causing the number of subclasses to grow explosively;
  • The class definition is hidden, or the class definition cannot be used to generate subclasses

participant

• Component: Define an object interface that can dynamically add responsibilities to these objects
• ConcreteComponent: Define an object, you can add some responsibilities to this object
• Decorator: Maintain a pointer to the Component object and define an interface consistent with the Component interface
• ConcreteDecorator: Adds responsibilities to components

cooperation

• Decorator forwards the request to the Component object, and may perform some additional actions before and after forwarding the request

Effect

• advantage:
  • More flexible than static inheritance, object behavior can be extended without creating new subclasses, and the ability to add or remove objects at runtime
  • Multiple decorators can be used to combine several behaviors
  • Single Responsibility Principle
  • Avoid classes at higher levels of the hierarchy that have too many characteristics. The Decorator pattern provides a "pay as you go" method to add responsibilities. He does not try to add functionality to a complex customizable class. Complex functionality can be combined from simple components.
• shortcoming:
  • A Decorator is not the same as its Component. Decorator is a transparent wrapper, you should not rely on object identity when using decorators
  • System design using the Decorator pattern results in lots of small objects that differ only in the way they are connected to each other, not their classes or their property values
  • When the Component class is already huge, the cost of using the Decorator mode is too high, and the Strategy mode is relatively better

accomplish

• Interface consistency: the interface of the decorated object must be consistent with the interface of the Component it decorates, so all concrete Decorator classes must have a common parent class
• Omit the abstract Decorator class: there is no need to define an abstract Decorator class when only one responsibility needs to be added
• Keep the Component class simple: To ensure interface consistency, components and decorators must have a common Component parent class, so it's important to keep this class simple and focus on defining the interface rather than storing data. The definition of data representation should be delayed to subclasses, otherwise the Component class will become too complex and bulky; the functions should not be too many, otherwise the subclasses will have some functions they do not need;
• Change the shell of the object and change the core of the object: Decorator can be regarded as the shell of an object, which can change the behavior of the object. Another method is to change the core of the object, such as the Strategy mode; to distinguish between these two modes: when the Component class is very large, the cost of using the Decorator mode is too high, and the Strategy mode is relatively better
• The specific implementation method (combined with the class diagram)
  • Make sure that business logic can be expressed with a base component and multiple optional additional layers.
  • Find out the generic methods of optional components and optional hierarchies (what are generic methods), create a component interface and declare those methods in it
  • Create a concrete component class and define its basic behavior
  • Create a decorated base class that uses a member variable to store a reference to the encapsulated object. This member variable must be declared as a component interface type, so that concrete components and decorations can be connected at runtime. The decorating base class must delegate all work to the encapsulated object.
  • Make sure all classes implement the component interface.
  • Extends the decorator base class to concrete decorators. Concrete decorators must perform their own behavior before or after invoking the superclass method (which always delegates to the wrapped object).
  • Client code is responsible for creating and composing the decorations into the form required by the client.

correlation model

• Adapter mode: decorators change the responsibility of the object without changing its interface; while the adapter gives the object a brand new interface
• Composite mode
• Strategy mode: two ways to change the object: decoration changes the appearance of the object, and the strategy mode changes the core of the object
  • Decorator mode is transparent to components
  • The component component in the Strategy itself knows which expansions may be made, so the corresponding strategy must be referenced and maintained

application and thinking

• Since the Decorator pattern only changes the component from the outside, the component does not need to know anything about its decoration, which means that these decorations are transparent to the component.
• Organize business logic into hierarchies, you can create a decoration for each layer, and combine various logic into objects at runtime

Class Diagram