晓子(咖啡店员),来一杯美式,加点威士忌和砂糖。
抱歉啊,猫。收银系统还没有你说的组合,要不换一个😁
🤨这系统不是你哥设计的,还没加上吗?
对啊,听他说加入了威士忌后,要修改的类太多了,还没来得及改完
行吧,那就只要美式+砂糖吧。系统的代码也发我一份看看吧,我也出出力
好嘞!谢谢啦
终于可以给别人改改代码了🥳
猫啊,在干嘛呢?
给别人改代码呢,这是部分类图,你也看看
(讲诉了事情的经过后),这么好心呢🤭
这个类的设计实在是不太合理,相信设计者现在也发现了弊端。一旦我们需要增加新的配料,或者修改价格,很轻松的就会出现类爆炸的问题,同时造成不小的维护困难。
这是我的改进方案,怎么样?
通过使用继承,在Beverage类中加入了实例变量,超类的cost()方法将会计算所有配料的价格,而子类依然可以覆盖cost()并扩展超类的功能,加入咖啡的价格。
但是这样也会出现一些问题的吧,我们使用了继承,如果她开发了新的口味,但是有的配料不适合这个口味,可以考虑考虑使用组合。
组合:
继承虽好,可不能过度使用, 利用继承设计子类,所有的子类都会继承到相同的行为,在编译时就已经静态的决定好了。但是组合却在运行时具有和继承相同的效果,动态的进行扩展,组合对象,无需修改现有的代码
装饰者模式(Decorator Pattern)允许向一个现有的对象扩展新的功能,同时不改变其结构。主要解决直接继承下因功能的不断横向扩展导致子类膨胀的问题,无需考虑子类的维护。提供了比继承更有弹性的方案。
Component(抽象构件):
public abstract class Beverage {public abstract double cost();
}
ConcreteComponent(具体构件):
public class Latte extends Beverage {@Overridepublic double cost() {System.out.println("Latte + 5$");return 5;}
}
public class Mocha extends Beverage {@Overridepublic double cost() {System.out.println("Latte + 9$");return 9;}
}
Decorator(抽象装饰类):
public abstract class MixedIngredients extends Beverage {public abstract double cost();
}
ConcreteDecorator(具体装饰类):
public class Sugar extends MixedIngredients {private static final int COST = 3;public final Beverage beverage;public Sugar(Beverage beverage) {this.beverage = beverage;}@Overridepublic double cost() {System.out.println("add Sugar 3$");return COST+beverage.cost();}
}
public class Whisky extends MixedIngredients {private static final int COST = 7;public final Beverage beverage;public Whisky(Beverage beverage){this.beverage=beverage;}@Overridepublic double cost() {System.out.println("add Whisky 7$");return COST+beverage.cost();}
}
上一篇:微机原理不挂科