设计模式学习第十三天

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);
    }

}

策略模式的封装类其实把算法或者策略的引用和算法封装了起来，把这种变化封装了起来，客户端只需要认识封装好的一个算法类就可以。

该策略模式的实现其实跟工厂模式差不多，都是封装成抽象父类，不同策略继承成子类，子类的引用利用多态：父类指向子类。然后把这个策略进行包装，包括公共的方法。

策略模式和简单工厂模式其实差不多，策略模式的理解就是封装了一种变化。客户端调用调用的是一个策略类的封装，而不是工厂生产子类，调用不同。换句话说只看见一个策略包装类，降低耦合度。

纯策略模式其实不好，策略模式和简单工厂模式结合好点。

总感觉简单工厂模式和策略模式大同小异。其实用哪个都差不多，我推荐简单工厂和策略模式的结合，毕竟只需要认识一个类，较少耦合度，起码表面光鲜靓丽。

单一职责原则：

如果一个类承担的责任过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软甲设计真正要做的许多内容，就是发现职责并把这些职责相互分离。

如果你能够想到多余一个的动机去改变一个类，那么这个类就具有多于一个的职责。

易维护、易扩展、易复用，灵活多样。

开放—封闭原则

软件实体应该可以扩展，但是不可以修改，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

拒绝不成熟的抽象和抽象本身一样重要。

开发人员仅对频繁变化的那一部分做出抽象。

两手准备并全力以赴。