山西面馆中的设计模式——装饰者模式

引言

在山西面馆吃鸡蛋面的时候突然想起装饰者这个模式,觉得面馆这个场景跟书中的星巴兹咖啡的场景很像,边吃边思考装饰者模式。这里也就依葫芦画瓢,换汤不换药的用装饰者模式来模拟一碗鸡蛋面是怎么出来的吧。吃货有吃货的方式来理解......这里先将书中讲到的例子放在前面,理论的东西,讲的还是比较具体的,只是觉得咖啡的例子不是太好理解,lz很土,几乎没喝过咖啡,不知道什么摩卡啊......,还是中国特色的例子更好理解。

为什么学设计模式?

答:觉得会设计模式的人,不仅仅是码农,更像艺术家!

为什么现在学设计模式?

答:不求精通,但求认识,接触过不少项目,有设计模式,而不认识,是我的损失,体会不到他的妙处,但不求它认识我。

装饰者到底装饰谁呢?

类,还是对象?

装饰者模式定义

动态地将责任附加到对象上。若要扩展功能,装饰者提供了比继承更有弹性的替代方案。(由定义可知,装饰对象的)

实例分析

星巴兹咖啡订单管理系统 管理、计算各种饮料的售价。

若顾客根据个人喜好,添加不同的调料,那么系统就要有根据调料的不同来计算价格,按照原来的设计,必定会出现下面的情况。

第一种方案设计:继承

有多少种口味的咖啡,你就得建多少种对应的类。烦不?

第二种方案设计:

思考

当哪些因素改变时会影响这个设计?

调料价钱的改变会使我们更改现有代码。

一旦出现新的调料,我们就需要加上新的方法,并改变超类中的cost()方法。

以后可能会开发出新饮料,对于这些饮料而言(冰茶),某些调料可能并不适合,但是在这个设计方式中,Tea子类仍将继承那些不合适的方法,比如:hasWhip()。 如何顾客想要双倍摩卡,怎么办?

......

设计原则(Open-Closed Principle)

类应该对扩展开放,对修改关闭。

我们的目标是允许类容易扩展,在不修改现有代码的情况下,就可搭配新的行为。如能实现这样的目标,其好处在于:这样的设计具有弹性,可以应对改变,可以接受新的功能来应对改变的需求。

如何让设计的每个部分都遵循开放-关闭原则?

这通常是无法做到的。要让OO设计同时具有开放性和关闭性,又不修改现有的代码,需要花费许多时间和努力。一般来说,我们没有足够的精力把设计的每个部分都这么设计,这可能只是一种浪费。 遵循开放-关闭原则,通常会引入新的抽象层次,增加代码的复杂度。你需要把注意力集中在设计中最有可能改变的地方,然后应用开放-关闭原则。

装饰者模式

星巴兹咖啡订单管理系统——使用装饰者模式

以饮料(Beverage)为主体,然后在运行时以调料(Condiment)来装饰(decorate)饮料

比如,顾客想要摩卡和奶泡深焙咖啡,那么: 取出一个深焙咖啡(DarkRoast)对象 以摩卡(Mocha)对象装饰它 以奶泡(Whip)对象装饰它 调用cost方法,并依赖委托(delegrate)将调料的价格加上去

步骤:

“装饰者模式”——特点

装饰者和被装饰对象具有相同的超类型 可以用一个或多个装饰者包装一个对象 由于装饰者和被装饰对象有相同的超类型,所以在任何需要原始对象(被包装)的场合,都可以用装饰过的对象代替她 装饰者可以在所委托被装饰者的行为之前或之后,加上自己的行为,以达到特定的目的 对象可以在任何时候被装饰,所以可以在运行时动态的、不限量的用需要的装饰者来装饰对象

装饰者模式类图关系

星巴兹咖啡销售系统装饰者模式类图关系

思考:为什么Decorate类扩展自Component类?

装饰者和被装饰者必须是一样的类型,我们在此使用继承达到“类型匹配” 类型匹配意味着装饰者和被装饰者具有相同的接口,从而装饰者可以取代被装饰者 新的行为并不是继承自超类,而是由组合对象得到,即所有饮料和调料可以更有弹性的加以混合和匹配 我们可以在任何时候,实现新的装饰者增加新的行为。如果依赖继承,每当需要新行为时,必须修改代码 Component类型可以使用抽象类,也可以使用接口

问题:如果有一张订单:“双倍摩卡豆浆奶泡拿铁咖啡”,应该如何进行设计?

这里代码的具体实现就不再写了,网上这样的代码太多了?

山西面馆中的“装饰者模式”

先上类图:直观形象

代码实现:

      /// <summary>
     ///抽象类 食物基类 其他类都继承自该类
     /// </summary>
     public abstract class Food
     {
         protected string description = "未知的饭";
         public virtual string GetDescription()
         {
             return this.description;
         }
         public abstract double Cost();
     }
       /// <summary>
     /// 所有配料的基类 继承自Food类 保持类型一致
     /// </summary>
     public abstract class Ingredients : Food
     {
        
     }

具体的配料:鸡蛋,西红柿类继承配料类

 public class Egg : Ingredients
     {
         Food meal;
         public Egg(Food meal)
         {
             this.meal = meal;
 
         }
         public override double Cost()
         {
             return  + meal.Cost();
         }
 
         public override string GetDescription()
         {
             return "鸡蛋"+meal.GetDescription();
         }
     }
 public class Tomato : Ingredients
     {
         Food meal;
         public Tomato(Food meal)
         {
             this.meal = meal;
 
         }
         public override double Cost()
         {
             return  + meal.Cost();
         }
 
         public override string GetDescription()
         {
             return "西红柿" + meal.GetDescription();
         }
     }

所谓的component类(Noodle)继承自Food类

   public class Noodle : Food
     {
         public Noodle()
         {
             description = "面";
         }
         public override double Cost()
         {
             return ;
         }
     }

控制台测试程序:

  class Program
     {
         static void Main(string[] args)
         {
             //创建被装饰的对象 noodle
             Food f1 = new Noodle();
             //用鸡蛋装饰
             f1 = new Egg(f1);
             //用西红柿装饰
             f1 = new Tomato(f1);
             Console.WriteLine(f1.GetDescription() + "\t" + f1.Cost() + "¥");
             Console.Read();
         }
     }

结果:

思考:装饰者模式是否对修改封闭,对扩展开放呢?

那么,测试一下,加入现在我想要一份酱爆鸡丁盖浇饭,该怎么实现?

 1  public class Rice : Food
 2     {
 3         public Rice()
 4         {
 5             description = "盖浇饭";
 6         }
 7         public override double Cost()
 8         {
 9             return 5.0;
10         }
11     }
 1  public class Chicken : Ingredients
 2     {
 3         Food meal;
 4         public Chicken(Food meal)
 5         {
 6             this.meal = meal;
 7         }
 8         public override string GetDescription()
 9         {
10             return "酱爆鸡丁" + meal.GetDescription();
11         }
12         public override double Cost()
13         {
14             return 9.0 + meal.Cost();
15         }
16     }
 1  class Program
 2     {
 3         static void Main(string[] args)
 4         {
 5             //创建被装饰的对象 noodle
 6             Food f1 = new Noodle();
 7             //用鸡蛋装饰
 8             f1 = new Egg(f1);
 9             //用西红柿装饰
10             f1 = new Tomato(f1);
11             Console.WriteLine(f1.GetDescription() + "\t" + f1.Cost() + "¥");
12             //创建被装饰的对象 米饭
13             Food f2 = new Rice();
14             //用酱爆鸡丁 装饰(将配料合并了)
15             f2 = new Chicken(f2);
16             Console.WriteLine(f2.GetDescription() + "\t" + f2.Cost() + "¥");
17             Console.Read();
18         }
19     }

结果:

很容易扩展吧?只需要加两个类继承对应的类就可以了,原来的内部代码不需要修改,就可以实现

总结

在我们的代码中,应该允许行为遵循对扩展开放-对修改关闭的原则,这样就可以无需修改现有的代码就可以实现我们扩展的功能。

装饰者模式意味着一群装饰者类,这些类用来包装具体组件。

装饰者反映出被装饰者的组件类型(具有相同的类型)

装饰者可以在被装饰者的行为前面或后面加上自己的行为,甚至将被装饰者的行为整个取代,而达到特定的目的。

可以用无数个装饰者包装一个组件。

装饰者一般对组件的客户是透明的,除非客户程序依赖于组件的具体类型。

装饰者会导致设计中出现许多小对象,如果过度使用,会让程序变得复杂。

(最近一直在看设计模式,上班下班的路上想,吃饭的时候也想,不求精通,只求在项目中遇到了,能认出他,不求他认识我)

参考书:

Head First 设计模式