Adorned with patterns

Adorned with patterns

The decorator mode dynamically attaches responsibility to the object. To extend functionality, decorators provide a more resilient alternative than inheritance.

Case

There is such a project to make a restaurant ordering system. The initial code structure is this way. There are many beverage inherited classes, and now the problem is that the price of milk has risen, so all the related classes, we have to adjust, such as the Milk,sugarandmilk class, there are many, we need to modify the method of the class one by another-developers do this kind of thing every time , it's going crazy! So we have to change the existing structure. The following diagram is a schematic, the actual figure, can not be so simple.

Design Issues:

1 "Class number explosion, there are many classes, difficult to maintain;

2 "The whole design is rigid;

3 The new functionality added by the base class cannot be used in subclasses;

Later, after a panel study, we decided to pull out the basic classes, for example, we made coffee into a separate class, other coffees, such as milk and coffee, and sweet coffee, and we only packed the material in a single class.

Improved design:

Detailed

1 "For drinks, we directly inherit the beverage class, directly put the quotation into the drinks category inside;

2 "and for some special drinks that need to be added, we do the cumulative operation. For example, I would like a cup of milk coffee, then the total Price = Coffee price + milk price

3 "It is easy to know the price of a different drink.

Code:

<?phpabstract class beverage{public $_name; Abstract public function cost ();}    The Decorator class Coffee extends beverage{public function __construct () {$this->_name = ' Coffee ';    } Public Function cost () {return 1.00; }}//The following three classes are decorator related classes class Condimentdecorator extends beverage{public function __construct () {$this->_name =    ' Condiment ';    } Public Function cost () {return 0.1;    }} class Milk extends condimentdecorator{public $_beverage;        Public function __construct ($beverage) {$this->_name = ' Milk ';        if ($beverage instanceof beverage) {$this->_beverage = $beverage;    }else exit (' Failure ');    } Public Function cost () {return $this->_beverage->cost () + 0.2;    }} class Sugar extends condimentdecorator{public $_beverage;        Public function __construct ($beverage) {$this->_name = ' Sugar ';         if ($beverage instanceof beverage) {   $this->_beverage = $beverage;        }else{exit (' Failure ');    }} public Function cost () {return $this->_beverage->cost () + 0.2; }}//Test CASE//1. Take a cup OF coffee $coffee = new coffee (); 2. Add Milk $coffee = new Milk ($coffee); 3. Add Sugar $coffee = new Sugar ($coffee); printf ("Coffee total:%0.2f yuan \ n", $coffee->cost ());

Summarize:

1. Decorators (Milk) and decorators (Coffee) must be of the same type. The aim is that the decorator must replace the adorned person. 2. Add behavior: When decorators and components are combined, new behaviors are added. Off topic:1. The use of inheritance to design subclass behavior is statically determined at compile time, and all subclasses inherit the same behavior. For example, Lao Tzu want to learn some kung fu, see you kid will Taijiquan, Lao Tzu only need to inherit you, Lao Tzu will be Taijiquan-hehe, then I will become your son, it seems that inheritance is to pay the price.  2. Combination, we can extend the behavior of the object, and dynamically expand it at run time. With the combination we can always add to the object the methods we didn't think of when we were designing the superclass, without changing the existing code. For example, I now have no internal force, suction Dafa, the monks, nuns, monks of internal forces (behavioral objects) are sucked over, that in the struggle (running), I can use different internal forces at any time, but also can not be indiscriminate absorption of internal forces, otherwise you will be possessed!  3. Classes should be open to extensions and closed for modifications. If every part of us is designed with a decorator pattern, it's a bit wasteful for the entire framework, and you're making it harder to code. So when do you use this model? We are generally used to change the place frequently. So how do we know which ones are often changed? This will require our experience and your knowledge of the industry in which you are located. We suggest that we usually show more examples.  4. The decoration mode injects elasticity into the design, but also adds a large number of small classes to the design, which occasionally makes it difficult for others to understand the design.  5. When using decorator mode, be especially careful with the inserted decorator. Because the adorner pattern relies on a particular type (beverage). Original address: http://www.cnblogs.com/baochuan/archive/2012/02/28/2371521.html

Adorned with patterns