Decorator pattern
First, decorator mode intention
Adding additional responsibilities to an object dynamically gives the Decorator pattern more flexibility in terms of adding functionality than subclassing. This pattern extends the functionality of objects in a way that is transparent to the client. \
Two, applicable environment
(1) Add responsibilities to a single object in a dynamic and transparent way without affecting other objects.
(2) Deal with responsibilities that can be undone.
(3) when the method of generating subclasses cannot be used for expansion. In one case, there may be a large number of independent extensions, and the number of subclasses to support each combination will explode. Another case might be because the class definition is hidden, or the class definition cannot be used to generate subclasses.
Iii. Participants
1.Component (base class of the decorated object)
Define an interface to objects to which responsibilities can be dynamically added.
2. ConcreteComponent (specificDecorated object)
Define an object to which you can add some responsibilities.
3.Decorator abstract class
Holds a pointer to the Component instancereference.Define an interface that is consistent with the Component interface.
4. Concretedecorators
The specific decoration object, to the internal holding of the specific decoration object, add specific responsibilities.
### 4
Five, involving roles
(1) Abstract component: Define an abstract interface to specify the class for which additional functionality is intended. (2) Concrete component: The class for which additional functionality is intended implements the interface for abstract component roles. (3) Abstract decorator: Holds references to concrete component roles and defines interfaces consistent with abstract component roles. (4) Concrete decorator: Implements the abstract decorator role, responsible for adding additional functionality to concrete artifacts. \
The most important aspect of the Decorator pattern is that abstract decorators hold concrete artifactsreference, which in turn decorates the concrete Component and has the same interface as the abstract Component, in this case, the abstract decorator implements the abstract Component interfacepublic abstract class Decorator implements Component
, so that the specific components can be decorated for many times.
Six, code implementation
6.1. Abstract Component
Define the function eat() of a concrete component, under which decorators perform further decorations.
/** * Public interface Component {void eat(); / / Public interface Component {void eat(); / / Public interface Component {void eat(); }Copy the code
6.2 Concrete component ConcreateComponent
This is the concrete modified object, just a simple function
/** * Classes to be attached, interfaces to implement abstract building roles * Concrete decorated objects, Public class ConcreateComponent implements Component{@override public void eat() { System.out.println(" I'm eating...") ); }}Copy the code
6.3 abstract decorator
Abstract decorator is an abstract class, in order to have consistent with abstract component structure, implement the abstract component structure, so it also can be used as a specific subclass of components to be decorated, abstract decorator concrete component reference at the same time, here to use the parent class reference (reference) abstract component to subclass object (incoming subclass object), The method eat() of abstract component is reimplemented, and the subclass of abstract decorator is modified eat(), which has reached the function of decorating concrete components and adding accessories.
package com.chb.f.DecoratorDesignPattern.b; /** * decorator abstract class: Holds a reference to a concrete Component role and defines an interface consistent with the abstract Component. * */ public abstract class Decorator implements Component{private Component Component; public void setComponent(Component component) { this.component = component; } @Override public void eat() { component.eat(); }}Copy the code
6.4 Concrete decorator ConcreateComponent
For the decorator, rewrite the eat() method, super.eat(). The function of the modified object is not changed, but additional functions are added
System.out.println("=========="); System.out.println(" B");Copy the code
Two decorators are provided
/** * Implement abstract decoration roles, responsible for adding additional functions to concrete components * concrete decoration objects, to the internal holding of concrete decoration objects, */ Public class ConcreteDectratorA extends Decorator{@override public void eat() {super.eat(); / / = = > com. Eat () System. Out. The println (" = = = = = = = = = = "); System.out.println(" B"); }} /** * Implement abstract decoration roles, responsible for adding additional functions to concrete components * concrete decoration objects, to the internal holding of concrete decoration objects, */ Public class ConcreteDectratorB extends Decorator{@override public void eat() {super.eat(); //====> setCom(com) com=da reEat(); System.out.println(" A"); } public void reEat() {system.out.println (); ); }}Copy the code
Client call
package com.chb.f.DecoratorDesignPattern.b; public class Test { public static void main(String[] args) { Component component = new ConcreateComponent(); // I'm eating... Decorator da = new ConcreteDectratorA(); Decorator db = new ConcreteDectratorB(); // Component.eat (); System.out.println(); // Decorate da.setComponent(component) for the first time; da.eat(); System.out.println(); Db.setcomponent (da); db.eat(); }}Copy the code
The same method is used to call eat(), but with the decorator decorating it more often,
I'm eating... I'm eating... ========== Specific decoration role B Lao Tzu at dinner... ========== specific decoration role B Lao Tzu to eat... Specific decoration character ACopy the code