public class CashContext {
CashSuper cs =null;
CashContext(Integer type) {
switch(type) {
case 0 :
cs = new CashNormal();
break;
case 1 :
CashReturn cr1 = new CashReturn("300","100");
cs = cr1;
break;
case 2:
CashRebate cr2 = new CashRebate("0.8");
cs = cr2;
break;
default :
break;
}
}
public double acceptCash(double money) {
return cs.acceptCash(money);
}
CashSuper cs =null;
CashContext(Integer type) {
switch(type) {
case 0 :
cs = new CashNormal();
break;
case 1 :
CashReturn cr1 = new CashReturn("300","100");
cs = cr1;
break;
case 2:
CashRebate cr2 = new CashRebate("0.8");
cs = cr2;
break;
default :
break;
}
}
public double acceptCash(double money) {
return cs.acceptCash(money);
}
}
策略模式的封装类其实把算法或者策略的引用和算法封装了起来,把这种变化封装了起来,客户端只需要认识封装好的一个算法类就可以。
该策略模式的实现其实跟工厂模式差不多,都是封装成抽象父类,不同策略继承成子类,子类的引用利用多态:父类指向子类。然后把这个策略进行包装,包括公共的方法。
策略模式和简单工厂模式其实差不多,策略模式的理解就是封装了一种变化。客户端调用调用的是一个策略类的封装,而不是工厂生产子类,调用不同。换句话说只看见一个策略包装类,降低耦合度。
纯策略模式其实不好,策略模式和简单工厂模式结合好点。
总感觉简单工厂模式和策略模式大同小异。其实用哪个都差不多,我推荐简单工厂和策略模式的结合,毕竟只需要认识一个类,较少耦合度,起码表面光鲜靓丽。
单一职责原则:
如果一个类承担的责任过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。
软甲设计真正要做的许多内容,就是发现职责并把这些职责相互分离。
如果你能够想到多余一个的动机去改变一个类,那么这个类就具有多于一个的职责。
易维护、易扩展、易复用,灵活多样。
开放—封闭原则
软件实体应该可以扩展,但是不可以修改,对程序的改动是通过增加新代码进行的,而不是更改现有的代码。
拒绝不成熟的抽象和抽象本身一样重要。
开发人员仅对频繁变化的那一部分做出抽象。
两手准备并全力以赴。