Introduced
The decorator pattern dynamically attaches responsibility to the object. To extend functionality, adorners provide a more flexible alternative than inheritance.
Mind Mapping
There is such a project to make a restaurant reservation system. The original code structure is like this. There are a lot of beverage inherited classes, now the problem is that the price of milk is going up, then all the related classes, we have to adjust, such as the Milk,sugarandmilk class, there are many, we need to modify the methods in the class--developers do this every time , it's going crazy! So we have to change the existing structure. The following diagram is a schematic, the actual figure, but not so simple.
Design issues:
1 The number of explosion, there are many classes, difficult to maintain;
2 "The whole design is inflexible;
3 new features added by base class cannot be used in subclasses;
There are many ways of reusing class methods, such as inheritance, composition, and delegation. Why do you always get used to inheritance? I think the Zend Framework also has this habit! Every time you find a corresponding method, always go up. --The digression!!!!
Later, after a panel study, we decided to pull out the basics, such as we made a separate class of coffee, other coffee, such as milk coffee, sweet coffee, and we only packaged the material in a separate class.
Improved design:
Detailed
1 for drinks, we directly inherit the beverage category, directly to the quotation into the drinks category;
2 and for some special drinks need to add seasoning, we do additive operation. For example, I would like a cup of milk coffee, the total Price = Coffee price + milk price
3 It is easy to know the price of a different drink.
Code
Copy Code code as follows:
<?php
Abstract class beverage{
Public $_name;
Abstract public function cost ();
}
Decorated Person class
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. Get a cup OF coffee
$coffee = new coffee ();
2. Add some milk
$coffee = new Milk ($coffee);
3. Add sugar
$coffee = new Sugar ($coffee);
printf ("Coffee total:%0.2f \ n", $coffee->cost ());
Summarize
1. The decorator (Milk) and the decorated person (Coffee) must be of the same type. The object is that the decorator must replace the decorated person.
2. Add behavior: When the decorator and component combinations, is to join the new behavior.
Digression:
1. The use of inheritance to design subclass behavior is statically determined at compile time, and all subclasses inherit to the same behavior. For example, I want to learn some kung fu, see you kid will Taijiquan, I just need to inherit you, I will also Taijiquan-oh, then I became your son, it seems that inheritance is to pay the price.
2. In combination, we can extend the behavior of objects and expand them dynamically at runtime. With the combination we can always add a method that we didn't think of when we designed the superclass to the object without changing the existing code. To make an analogy, Lao Tze now has no internal force, suction power Dafa, the monk, nun, Taoist's internal force (behavior object) all suck over, that in the struggle (run), Lao Tze can use different internal force at any time, but also can not indiscriminately suction internal force, or you will be out of possession!
3. Classes should be open to extensions and closed for modification. If each of our parts were designed with the decorator pattern, it would be a bit wasteful for the entire framework, and you would make the code more difficult. So when is this mode used? We usually use it in places where we often change. So how do we know which ones are constantly changing? This will require our experience and your knowledge of the industry. Suggest that you usually have more examples.
4. Decorative patterns inject flexibility into the design, but at the same time add a large number of small classes in the design, which occasionally makes it difficult for others to understand this design.
5. When using the decorator mode, be especially careful about the decorator who inserts. Because the adorner pattern relies on a particular type (beverage).
6. In order to use the decorator mode well, we also need to cooperate with the Factory mode and generator mode, but today we only say the decorator mode. If you want to know more, please listen to let's.
References: Head of the design model
