Shulou(Shulou.com)06/03 Report--

Decoration mode

Decorator mode: dynamically attach responsibilities to objects. To extend the functionality, the decorator provides a more flexible alternative to inheritance.

The roles of the decoration model are as follows:

Abstract component role (Component): gives an abstract interface to standardize objects that are ready to receive additional responsibilities.

Concrete component roles (Concrete Component): define the classes that will receive additional responsibilities.

Decorator: holds a reference to a Component object and defines an interface consistent with the abstract component interface.

Specific decorative roles (Concrete Decorator): responsible for "affixing" additional responsibilities to component objects. The class diagram is as follows:

The characteristics of the decoration model:

Decorative objects and real objects have the same interface. This allows the client object to interact with the decoration object in the same way as the real object.

The decoration object contains a reference to a real object (reference).

The decorating object receives all requests from the client, and it forwards these requests to the real object.

Decorating objects can add some functionality before or after forwarding these requests.

This ensures that at run time, additional functionality can be added externally without modifying the structure of a given object.

Shortcomings of the decoration model:

Decoration patterns can lead to many small classes in the design, which can complicate the program if overused.

The Decoration pattern is programmed against abstract component (Component) types. However, if you want to program against specific components, you should rethink your application architecture and whether the decorator is appropriate. Of course, you can also change the Component interface to add new public behavior to achieve a "translucent" decorator mode. Better choices should be made in practical projects.

Scenarios for the use of decorative mode:

Suitable for permutation and combination scheduling of multiple interfaces in the default goal implementation

Suitable for selective extension of default goal realization

It is suitable for situations where the implementation of the default target is unknown or not easy to expand.

Example 1: there are several kinds of coffee in the coffee shop, each with its own price, ingredients, etc., the class diagram is as follows

The cause of the problem: coffee can put some sugar and other seasonings, there are many kinds of seasonings, N subcategories have been added to correspond to the relationship between coffee, price and seasonings, and there is a great challenge in later maintenance. The class diagram is as follows:

Solution: we can use the decoration mode to solve the problem, and the final class diagram is as follows:

Example 2: expand the IMaple O in JAVA, read the data in the file, and convert it to uppercase output.

Analysis: the adapter pattern is used in the Istroke O framework in JDK. The class diagram is as follows:

Description: abstract construction role (InputStream), decoration role (FilterInputStream), concrete decoration (BufferdInputStream, etc.), concrete construction role (FileInputStream, etc.)

Implementation: we look at the class diagram, we inherit FilterInputStream, override the read method to meet this requirement.

Design principle: classes should be open to extensions and closed to modifications.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.