星巴克咖啡订单项目(咖啡馆):
- 咖啡种类/单品咖啡:Espresso(意大利浓咖啡)、ShortBlack、LongBlack(美式咖啡)、Decaf(无因咖啡)。
- 调料:milk、Soy(豆浆)、Chocolate。
- 要求在扩展新的咖啡种类时,具有良好的扩展性、改动方便、维护方便。
- 使用OO来计算不同种类咖啡的费用,客户可以点单品咖啡,也可以单品咖啡+调料的组合。
常见的解决方案:
但是这种方案会存在典型的类爆炸问题!
解决星巴克订单问题分析:
1)Drink是一个抽象类或者接口,表示饮料。
2)Desc是对咖啡的描述,表示是拿铁还是Decaf。
3)Cost表示计算费用,Drink类做成一个接口或者抽象方法。
4)Decaf单品咖啡。继承Drink并且实现cost方法。
5)Express&Drink就是单品+调料,这样的组合会有很多。
6)问题是这样设计会有很多类,当我们增加一个单品咖啡或者调料时,类的数量就会倍增,就会出现类爆炸。
方案一会造成类爆炸,主要原因是单品+调料组成造成类爆炸问题,因此可以将调料内置到Drink中,这样就不会造成类数量过多,从而提高项目的维护性(如图所示)。
说明:milk、soy、chocolate可以设置成boolean型,表示是否需要添加。
方案二可以控制类的数量,一定程度上解决了类爆炸问题,但没有遵守ocp原则,尤其在新增一种调料时,需要修改代码。考虑到要添加多份调料时,可以将hasMilk返回对应的int型就可以了。可以考虑装饰者模式!
装饰者模式基本介绍:
- 装饰者模式:动态的将新功能添加到对象中,在对象功能扩展方面,他比继承者更有弹性。装饰者模式也体现了ocp原则。
- 这里提到的动态的将新功能添加到对象和ocp原则,在后面的实际应用中以代码的形式体现。
装饰者模式原理:
- 装饰者模式就像打包一个快递。
- 主体是比如说:陶瓷、衣服(Component)
- 包装:比如:报纸、泡沫、塑料、纸板、木板(Decorator)
- Component主体:比如说前面的drink。
- ConreteComponent和Decorator:ConreteComponent:具体的主体,比如说前面的各种单品咖啡。
- Decorator:装饰者,比如说各种调料。
- 在如图的Component和ConreteComponent之间,如果ConreteComponent类很多,可以设计一个缓冲层,将共有的部分提取出来,抽象成一个类。