decorative pattern
Decorator Pattern : Dynamically attach responsibilities to objects. To extend functionality, decorators provide a more flexible alternative to inheritance.
The roles of the decoration mode are as follows:
Abstract Component Role (Component): Gives an abstract interface to standardize objects that are prepared to receive additional responsibilities.
Concrete Component: Defines classes that will receive additional responsibilities.
Decorator: Holds a reference to a Component object and defines an interface consistent with the abstract component interface.
Concrete Decorator: Responsible for "sticking" additional responsibilities to component objects. The class diagram is as follows:
Features of decoration mode :
Decorated objects and real objects have the same interface. This way the client object can interact with the decorated object in the same way as the real object.
The decorated object contains a reference to the real object.
The decorated object receives all requests from the client, and it forwards these requests to the real object.
Decorated objects can attach some functionality before or after forwarding these requests.
This ensures that additional functionality can be added externally at runtime without modifying the structure of a given object.
Disadvantages of decoration mode:
Decorative patterns can lead to many subclasses in the design, which, if overused, can complicate the program.
The decoration pattern is for programming with abstract components (Component) types. However, if you are programming against specific components, you should rethink your application architecture and whether decorators are appropriate. Of course, you can also change the Component interface, add new public behaviors, and implement the "translucent" decorator pattern. In the actual project to make a better choice.
Use scenarios of decoration mode:
Suitable for permutation and combination scheduling of multiple interfaces in the default target implementation
Suitable for selective extensions to the default target implementation
Suitable for cases where the default target implementation is unknown or not easily extensible.
Example 1 : There are several types of coffee in the coffee shop, each with its own price, ingredients, etc. The class diagram is as follows;
The problem arises: coffee can be put in some condiments such as sugar. There are many kinds of condiments. N sub-classes have been added to correspond to the relationship between coffee, price and condiments. Later maintenance is a big challenge. The class diagram is as follows:
Solution: We can use the decoration mode to solve the problem. The final class diagram is as follows:
Example 2 : Extend the I/O in JAVA, read the data in the file, and convert it into uppercase letters for output
Analysis : The adapter pattern is used in the I/O framework in the JDK. The class diagram is as follows:
Description : abstract construction role (InputStream), decorative role (FilterInputStream), concrete decoration (BufferdInputStream, etc.), concrete construction role (FileInputStream, etc.)
Implementation : Let's look at the class diagram. We inherit FilterInputStream and override the read method to meet this requirement.
Design Principle : Classes should be open for extension and closed for modification .