装饰器模式解决的问题

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

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

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

// 区域抽象类  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

总结

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

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