设计模式-总结篇

   《大话设计模式》终于到了总结这一天，这本书主要讲述了２３个设计模式和六大原则。而六大原则却是这２３个设计模式的核心。每个模式都遵从一种或几种原则，所以在此针对六大原则进行了相关总结。

 

单一职责原则

    定义：导致类变更的原因，应该仅有一个。通俗的说，即一个类只负责一项职责。

说到单一职责原则，很多大鸟都会不屑一顾。因为它太简单了，稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。

    但这也仅仅是对大鸟而言，对于我们这些初入编程的菜鸟来说依旧需要细心学习。还记得作品展时期，刚刚动手做的时候都会建立一个Ｆｏｒｍ１　这样的窗体，于是乎各种各样的代码像ＡＰＩ函数呀，各种引用呀，实现各种功能的Function等等都放在了From１中，看着自己写了这么多代码心里还美滋滋的，但是当出现错误或者需要改动的时候就傻眼了。这样不仅维护麻烦，缺乏灵活性，更别提复用了。所以说单一职责原则是真重要。

    优点 ：

• 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；    
• 提高类的可读性，提高系统的可维护性；
• 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。    

依赖倒置原则

    定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。就是要针对接口编程，不要对实现编程。

    我们常用之物电脑的ＣＰＵ，内存条，硬盘等都是在针对接口设计的，每个都有规定的接口，当某个部件损坏时只需要更换新的即可，而如果ＣＰＵ，内存条等部件是依赖于具体主板的话，当主板坏了或者更换其它型号时，其他的部件也就都作废了。

    所以说无论是高层模块（主板）还是底层模块（ＣＰＵ）都应该依赖于抽象即接口或抽象类。因为相对于细节的多变性，抽象的东西要稳定的多。

 

里氏代换原则

    先不说内容，刚看到这个原则名字的时候脑子里就充满了疑惑，为什么叫这么个奇怪的名字？

其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。所以就按其姓氏命名了。

    定义：子类型必须能够替换掉它们的父类型；也就是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它觉察不出父类对象和子类对象的区别。也就是说在软件里边，把父类都替换成它的子类，程序的行为没有变化。

    正是因为这个原则才使得继承复用成为了可能，只有当子类可以替换掉父类，软件单位的功能不受影响时，父类才能真正被复用，而子类也能够在父类基础上增加新的行为。比如：Ｃａｔ继承Animal类，以动物的身份拥有吃，喝，跑等行为，可当我们需要Ｄｏｇ，Ｐｉｇ也继承Animal类时，是需要更改实例化的地方即可，其他地方不用改动。

 

合成聚合复用原则

    定义：尽量使用合成/聚合，尽量不使用类继承。合成聚合是“hasa”的关系，而继承是“isa”的关系。

    上面刚刚讲了继承，觉得继承真是方便又强大，但仔细分析下，继承的双方父类和子类的关系，他们是紧密依赖的，父类变，子类必变。所以继承是一中强耦合的结构限制了系统的灵活性，所以我们要慎用继承，不是“isa”关系，我们一般不要用继承。优先使用合成聚合复用原则，有助于保持每个类的封装，降低继承的层次。

 

迪米特法则

    定义：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要，调用另一个类的某一个方法时，可以通过第三者转发这个调用。

    类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。如何避免这种情况呢？那就是尽量降低类与类之间的耦合，这也正是迪米特法则的目标。

 

开闭原则

    定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

    现在来说说最后一个原则—开闭原则，之所以把它放在最后来说，不是因为它不够重要，相反他是最重要的一个。

    开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活易扩展的系统，这也正是所有设计模式的最终目的。其实，我们遵循设计模式前面5大原则，以及使用23种设计模式的目的就是遵循开闭原则。也就是说，只要我们对前面5项原则遵守的好了，设计出的软件自然是符合开闭原则的，这个开闭原则更像是前面五项原则遵守程度的“平均得分”，前面5项原则遵守的好，平均分自然就高，说明软件设计开闭原则遵守的好；如果前面5项原则遵守的不好，则说明开闭原则遵守的不好。

                

作者把学习设计模式的学习分为了四个境界

１.没学前是一点不懂，根本想不到用设计模式，设计的代码很糟糕。

２.学了几个模式后，很开心，于是到处想着要用自己学过的模式，于是时常造成误用模式而不自知。

３.学完全部模式时，感觉诸多模式极其相似，无法分清模式之间的差异，有困惑，但深知误用之害，应用之时有所犹豫。

４.灵活应用模式，甚至不应用具体的某种模式也能设计出非常优秀的代价，以达到无剑胜有剑的境界。

 

   显然，我们现在正处于第三境界，困惑各种模式之间的差别。但是也没必要纠结，学习不是一蹴而就的事，马上就要开机房收费系统重构版了，这正好是个亮剑练手的机会。

   不忘初心方得始终：学习设计模式的目的就是设计出易维护，易扩展，易复用，灵活性好的程序。向着这个方向努力！