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

This article mainly explains "detailed explanation of decorator pattern in Java design pattern". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn the detailed explanation of the decorator pattern in the Java design pattern.

Catalogue

Introduction

Role

Sample code

The example of Starbucks coffee

Option one

Solution 2: build the seasoning into the Drink class

Plan 3: decorator mode

Code demonstration

The simplification of the decorator model

The requirement of transparency

A translucent decorative mode

The advantages of decorative mode

The shortcomings of the decoration mode

Matters needing attention in decoration mode

Applicable scenario

Application of Design pattern in JAVA I _ Band O Library

The difference between transparent and translucent decoration modes

Introduction

Decorator pattern (Decorator Pattern): dynamically adds some additional responsibilities to an object, and in terms of adding object functionality, decorator patterns are more flexible than generating subclass implementations. Decoration pattern is a kind of object structure pattern.

In the decorator pattern, in order to make the system more flexible and extensible, we usually define an abstract decoration class and take the concrete decoration class as its subclass.

The decoration mode dynamically adds more responsibility to an object in a way that is transparent to the customer. In other words, the client does not feel that the object is any different before and after decoration. The decoration mode can extend the functionality of the object without using to create more subclasses.

The class diagram of the decoration mode is as follows:

Role

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

ConcreteComponent (concrete artifacts): define a class that will receive additional responsibilities.

Decorator (Abstract Decoration Class): holds an instance of a Component object and defines an interface consistent with the interface of the abstract component.

ConcreteDecorator (concrete Decoration Class): responsible for "pasting" additional responsibilities to component objects.

Because both the concrete component class and the decoration class implement the same abstract component interface, the decoration pattern dynamically attaches more responsibility to an object in a way that is transparent to the client, in other words, the client does not feel that the object is any different before and after decoration. The decoration pattern can extend the functionality of the object without creating more subclasses.

The core of decoration pattern lies in the design of abstract decoration class.

Sample code

Abstract component role

Public interface Component {public void sampleOperation ();}

Specific component role

Public class ConcreteComponent implements Component {@ Override public void sampleOperation () {/ / write relevant business codes}}

Decorative role

Public class Decorator implements Component {private Component component; public Decorator (Component component) {this.component = component;} @ Override public void sampleOperation () {/ / delegate to component component.sampleOperation ();}}

Specific decorative role

Public class ConcreteDecoratorA extends Decorator {public ConcreteDecoratorA (Component component) {super (component);} @ Override public void sampleOperation () {super.sampleOperation (); / / write related business codes}} public class ConcreteDecoratorB extends Decorator {public ConcreteDecoratorB (Component component) {super (component);} @ Override public void sampleOperation () {super.sampleOperation () / / write the relevant business code}} Starbucks Coffee example

Option one

Add coffee with different seasonings, such as steamed milk (Steamed Milk), soy milk (Soy), Mocha (chocolate flavor) or covered with milk foam. Starbucks will charge different fees according to the seasoning added. So the order system must take into account these seasoning parts.

Solution 2: build the seasoning into the Drink class

Although this design meets the current needs, let's think about what we will do if the following happens.

Changes in ① and seasoning prices will cause us to change the existing code.

②, once a new seasoning appears, we need to add a new method and change the cost () method in the superclass.

③, new drinks may be developed in the future. For these drinks (for example, iced tea), some seasonings may not be suitable, but in this design, the Tea (tea) subclass will still inherit those methods that are not suitable, such as: hasWhip () (with milk foam).

④, what if a customer wants a double mocha?

Obviously, the above design can not fundamentally solve the problems we encounter. And this design violates the principle of opening and closing (classes should be open to extensions and closed to modifications. ).

So what are we gonna do? Well, the decorator can solve all the above problems perfectly. Let's have a cafe with very nice design.

Plan 3: decorator mode

The Coffee here is a buffer layer that is responsible for extracting what all specific coffee has in common.

Code demonstration

Beverage abstract class:

Public abstract class Drink {protected String decription= "; / / describe public String getDecription () {return decription;} public abstract Integer cost (); / / return the price of the beverage}

Buffer layer: extract the common characteristics of all coffees, that is, calculate the price

/ / buffer layer-public abstract class Coffee extends Drink {/ / Common characteristics extracted from all types of coffee: calculate the price @ Override public Integer cost () {/ / the price accumulates from 0 to return 0;}}

Specific types of coffee:

Public class LongBlack extends Coffee {LongBlack () {decription= American Coffee;} @ Override public Integer cost () {return 15;}} public class ChinaBlack extends Coffee {ChinaBlack () {decription= "Chinese Coffee";} @ Override public Integer cost () {return 10 }} public class Espresso extends Coffee {/ / set description information Espresso () {decription= "Italian coffee";} @ Override public Integer cost () {/ / Italian coffee 20 yuan return 20;}}

Abstract decorator

/ / decorator public abstract class Decorator extends Drink {@ Override public abstract String getDecription ();}

Specific decorator-that is, seasoning

Public class Milk extends Decorator {Drink drink; Milk (Drink drink) {this.drink=drink;} @ Override public String getDecription () {return "added milk" + this.drink.getDecription ();} @ Override public Integer cost () {return this.drink.cost () + 3 }} public class Chocolate extends Decorator {/ / record the drink with an instance variable, that is, the decorated Drink drink; Chocolate (Drink drink) {this.drink=drink;} @ Override public String getDecription () {return "chocolate added" + drink.getDecription () } @ Override public Integer cost () {/ / add seasoning price to the original beverage price return 5+drink.cost ();}}

test

Public class test {@ Test public void test () {/ / simulate placing an order / / first order an American coffee without any seasoning Drink drink=new LongBlack (); System.out.println ("bought" + drink.getDecription () + "spent" + drink.cost ()); / / add a chocolate drink=new Chocolate (drink) to American coffee System.out.println ("bought" + drink.getDecription () + "spent" + drink.cost ()); / add a milk drink=new Milk (drink) to American coffee; System.out.println ("bought" + drink.getDecription () + "spent" + drink.cost ()); / / add drink=new Chocolate (drink) to milk and chocolate again System.out.println ("bought" + drink.getDecription () + "spent" + drink.cost ()); drink=new Milk (drink); System.out.println ("bought" + drink.getDecription () + "spent" + drink.cost ()); System.out.println ("= ="); / / simplified Drink d=new Chocolate (new Milk (new ChinaBlack () System.out.println ("bought" + d.getDecription () + "spent" + d.cost ());}}

The simplification of the decorator model

In most cases, the implementation of the decoration pattern is simpler than the schematic example given above.

If there is only one ConcreteComponent class, consider removing the abstract Component class (interface) and making Decorator a ConcreteComponent subclass. As shown in the following figure:

If there is only one ConcreteDecorator class, there is no need to create a separate Decorator class, but you can merge the responsibilities of Decorator and ConcreteDecorator into one class. You can do this even when there are only two ConcreteDecorator classes. As shown in the following figure:

The requirement of transparency

The transparency of decorative mode to the client requires the program not to declare a variable of type ConcreteComponent, but rather to declare a variable of type Component.

Point to the concrete subclass with the top-level abstract parent class, and realize the transparency requirement in the form of polymorphism

It should be written like this:

Drink drink=new LongBlack (); / / add a chocolate drink=new Chocolate (drink) to American coffee.

Instead of writing like this.

Drink drink=new LongBlack (); / / add a chocolate Chocolate drink=new Chocolate (drink) to American coffee; translucent decoration mode

However, pure decorative patterns are hard to find. The decoration pattern is intended to enhance the performance of the classes under consideration without changing the interface.

When enhancing performance, it is often necessary to establish new and open methods.

For example, chocolates can be sold separately, that is, chocolate bars can be sold separately. Then a new sell method needs to be added to the chocolates to sell separately.

As a result, most of the implementation of decoration patterns is "translucent" rather than completely transparent. In other words, the decoration mode is allowed to change the interface and add new methods. This means that the client can declare variables of type ConcreteDecorator so that it can call methods that are unique to the ConcreteDecorator class:

Drink drink=new LongBlack (); / add a chocolate Chocolate drink=new Chocolate (drink) to American coffee; / / sell chocolate bars drink.sell ()

The translucent decoration mode is between the decoration mode and the adapter mode. The adapter pattern is intended to change the interface of the class under consideration, and can also enhance or change the functionality of the class under consideration by rewriting one or more methods or adding new methods. Most decoration modes are actually translucent decoration modes, which are also called semi-decoration and semi-adapter modes.

The advantages of decorative mode

For extending the functionality of an object, the decoration mode is more flexible than inheritance and does not result in a sharp increase in the number of classes.

The function of an object can be extended in a dynamic way, and different behaviors can be achieved by selecting different specific decoration classes at run time through configuration files.

You can decorate an object many times. By using different specific decoration classes and the arrangement and combination of these decoration classes, you can create a combination of many different behaviors and get more powerful objects.

Specific component classes and specific decoration classes can be changed independently, users can add new specific component classes and specific decoration classes according to their needs, and the original class library code does not need to be changed, in line with the "opening and closing principle".

The shortcomings of the decoration mode

When using decorative mode for system design, there will be a lot of small objects. The difference between these objects lies in the way they are connected to each other, rather than their different classes or attribute values. The generation of a large number of small objects is bound to occupy more system resources and affect the performance of the program.

Decoration mode provides a more flexible solution than inheritance, but it also means that it is more prone to errors and difficult to troubleshoot than inheritance. For objects decorated many times, finding errors during debugging may need to be checked step by step, which is more tedious.

Matters needing attention in decoration mode

(1) try to keep the interface of the decoration class the same as that of the decorated class, so that for the client, both the object before decoration and the object after decoration can be treated consistently. That is to say, where possible, we should try to use transparent decoration mode.

(2) try to keep the concrete component class as a "light" class, that is to say, don't put too much behavior in the concrete component class, we can extend it through the decoration class.

(3) if there is only one concrete component class, the abstract decoration class can be used as a direct subclass of the concrete component class.

Applicable scenario

Add responsibilities to individual objects in a dynamic and transparent manner without affecting other objects.

Decorative mode can be used when the system cannot be extended by inheritance or when inheritance is not conducive to system expansion and maintenance. There are two main types of situations in which inheritance cannot be adopted: the first is that there are a large number of independent extensions in the system, and a large number of subclasses will be generated to support each extension or the combination between them, resulting in an explosive increase in the number of subclasses; the second is because classes have been defined as cannot be inherited (such as final classes in Java)

Application of Design pattern in JAVA I _ Band O Library

The most famous application of decorative patterns in the Java language is the design of the Java Ipaw O standard library.

Because the Java I Pot O library requires a variety of combinations of performance, if the performance is implemented using inherited methods, then each combination requires a class, which will result in a large number of classes with duplicate performance. If the decorative mode is used, the number of classes will be greatly reduced and the repetition of performance can be minimized. Therefore, the decoration mode is the basic mode of the Java Imax O library.

The object structure diagram of the Java I _ plank O library is as follows, and because there are so many objects in Java I _ map O, only part of the InputStream is drawn.

The following is an example of a simple operation to read the contents of a file using the Imax O stream.

Public class IOTest {public static void main (String [] args) throws IOException {/ / streaming read file DataInputStream dis = null; try {dis = new DataInputStream (new BufferedInputStream (new FileInputStream ("test.txt") / / read file contents byte [] bs = new byte [dis.available ()]; dis.read (bs); String content = new String (bs); System.out.println (content);} finally {dis.close ();}

Observe the above code, you will find that the innermost layer is a FileInputStream object, and then pass it to a BufferedInputStream object, after BufferedInputStream processing, and then pass the processed object to the DataInputStream object for processing, this process is actually the assembly process of the decorator, the FileInputStream object is equivalent to the original decorated object, while the BufferedInputStream object and DataInputStream object are equivalent to the decorator.

The difference between transparent and translucent decoration modes

The ideal decoration mode not only enhances the function of the decorated object, but also requires that the interface of the specific component role and the decorative role is completely consistent with that of the abstract component role.

This is not the case with the adapter pattern, which in general does not require enhancements to the functionality of the source object, but changes the interface of the source object to match the target interface.

There are two kinds of decoration modes: transparent and translucent, and the difference between them is whether the interface of the decorative role is exactly the same as that of the abstract component role.

The transparent decoration mode is also the ideal decoration mode, which requires that the interface of the concrete component role and the decoration role is completely consistent with that of the abstract component role.

On the contrary, if the interface of the decorative role is not consistent with that of the abstract component role, that is to say, the interface of the decorative role is wider than that of the abstract component role, the decorative role has actually become an adapter role. This decorative pattern is also acceptable, called the "translucent" decorative mode, as shown in the following figure.

In the adapter pattern, the interface of the adapter class usually overlaps with that of the target class, but it is often not exactly the same. In other words, the interface of the adapter class is wider than that of the decorated target class.

Obviously, the translucent decoration mode is actually a gray area between the adapter mode and the decoration mode. If the decoration mode and adapter mode are merged into a "packaging mode", then the translucent decoration mode can be the representative of this combined "packaging mode".

At this point, I believe you have a deeper understanding of the "detailed interpretation of the decorator pattern in the Java design pattern". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.