《大话设计模式》——六大原则

       谈到设计模式，它是骨灰级任务给我们总结的经验，也是我们对面向对象编程学习的深入。而设计模式中的六大原则，则是我们在学习它时要遵循的规则。下面宏观的看一看六大原则的导图吧！

    一、导图分析

    二、导图分析

    1、单一职责：就一个类而言，应该仅有一个引起它变化的原因。

    问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

    解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

    2、里氏转换原则：子类型必须能够替代它们的父类型。用接地气的话说就是：子类可以扩展父类的功能，但不能改变父类原有的功能。这个原则是开放封闭原则的基础。因为有了它才可以实现继承，才能实现可扩展。

    问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

    解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。

    3、开放/封闭原则：软件实体（类、模块、函数、等等）应该可以扩展，但是不可以修改。

    问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

   解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。具体的例子见书中的简单工厂模式。

   4、依赖倒置原则：高层模块不应该依赖于低层模块，两个都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。

  问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

   解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。具体可参照书中小菜修电脑和修收音机例子。

    5、迪米特法则：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果一个类需要调用另一个类的某一个方法的话，可以通过第三着转发这个调用。

    问题由来：类A想调用类B的方法P1，但是P1是私有的方法，类A不能与类B直接通信。

    解决方案：给类B抽象个接口，类A直接调用类B的接口就行了。具体可参照小菜第一天上班的例子。

    6、合成/聚合复用原则：尽量使用合成/聚合，尽量不使用继承。     问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。

   解决方案：尽量降低类与类之间的耦合。具体例子见书中手机软件何时统一的问题。

    三、小结

      如果把设计模式比喻成一场篮球比赛的话，进攻可以封装成一个类，继承就是三步上篮，多态就是花样式上篮，那么，六大原则就是裁判。我学设计模式的感受就是不断的玩转抽象、继承和多态，有一种爬金字塔的感觉，越网顶层爬就越尖越细。