装饰器模式解决的问题

修饰模式，是面向对象编程领域中，一种动态地往一个类中添加新的行为的设计模式。就功能而言，修饰模式相比生成子类更为灵活，这样可以给某个对象而不是整个类添加一些功能。

将所有的功能建立在继承体系上会导致系统中的类越来越多，而且当你又要修改他们的分支的时候，可能还会出现重复代码

我们来看下面这个例子，为了计算一块区域的价值，我们把代码写成下面这个样子：

// 区域抽象类
abstract class Area
{
    abstract public function treasure();
}
//森林类，价值100
class Forest extends Area 
{
    public function treasure()
    {
        return 100;
    }
}
//沙漠类，价值10
class Desert extends Area
{
    function function treasure()
    {
        return 10;
    }
}

上面的代码看上去好像没有什么问题，但是如果需要给一片被破坏的森林计算价值怎么办呢，添加DamageForest子类么？显然是不可行的，因为很有可能还有其他很多类型叠加的类，这会导致类中可能会有重复的代码，且子类也会变的越来越多。

装饰器模式的实现

装饰器模式使用组合和委托，而不是使用继承来解决上述的问题，我们在来看下面改良过的代码：

// 区域抽象类
abstract class Area
{    
    abstract public function treasure();
}

//森林类，价值100
class Forest extends Area 
{
    public function treasure()
    {
        return 100;
    }
}
//沙漠类，价值10
class Desert extends Area
{
    function function treasure()
    {
        return 10;
    }
}
//区域类的装饰器类
abstract class AreaDecorateor extends Area
{
    protected $_area = null;

    public function __construct(Area $area)
    {
        $this->_area = $area;
    }
}

//被破坏了后的区域，价值只有之前的一半
class Damaged extends AreaDecorateor
{
    public function treasure()
    {
        return $this->_area->treasure() * 0.5;
    }
}

//现在我们来获取被破坏的森林类的价值
$damageForest = new Damaged(new Forest());
echo $damageForest->treasure();  //返回50

总结

上面的调用方法很像建立了一个管道，装饰器模式经常被用于创建过滤器。

可以看到，这样的模型很具有扩者性，我们可以轻松的添加其他装饰器给区域对象，且不需要更改其他类，