装饰者模式（一）

背景

假设我们现在要为沙县小吃创建一个应用程序，我们需要对沙县小吃进行建模。假设一开始他们提供了鸡腿饭、鸭腿饭、大肉面三种饭。刚刚开始的时候我们使用了继承来实现，而且将公共的操作放在了抽象的Snack类中。

 

    每种饭的价格不一样，所以在每个子类中都重写了getCost()方法。现在顾客除了点鸡腿饭、鸭腿饭、大肉面之外，还想加上青菜、蒸蛋、土豆以及再加一个鸡腿等等需求。按照现在的方式针对上面的需求有两种实现方式。

第一种

将加了额外项的看成是一个独立的菜种继承Snack，并覆盖它的getCost()方法，在这个方法中计算价格。

以这种方式来实现的缺点是每增加一种配菜就需要增加一个子类，随着时间的推移会出现很多类，这到后期会导致项目很难维护。

第二种方式

在父类中定义配菜以及是否存在配置的方法以及一个获取价格的方法（getCost），在子类中覆盖父类的

 使用这种方式，存在一下几个缺点：

1. 一旦出现新的配菜，我们就需要在父类中增加新的方法，并修改getCost方法
2. 并不是每个配菜都适合所有的饭，这样就造成类方法的冗余
3. 很难处理客户给饭加双份配菜的情况