【23种设计模式从零学1—设计模式原则】

写在前面：

    设计模式能在不同的场景中得到反复推敲，实践，必然有其精华之处，这篇文章就带你揭开设计模式这本程序界的《孙子兵法》的精髓与奥妙~

一、单一职责原则：

官方论述：

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

个人理解：

                让每个类尽可能只做一件事，类之间的业务关联尽量减少，理想化是完全无关联，即解耦。

这样做的优点：

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

二、开放封闭原则：

官方论述：

                   软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。

个人理解：

           你设计的时候，时刻要考虑，尽量让这个类足够好，写好了就不要去修改了，如果新需求来，最好的方式是我们增加一个类，原来的代码能不动则不动，可以避免其他对这个类有依赖类的不必要的麻烦。

这样做的优点：

           A、对扩展开放:意味着有新的需求或变化时，可以对先有代码进行扩展，以适应新的情况。

           B、对修改封闭:意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。

           也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

三、依赖倒转原则：

官方论述：

                  依赖倒置原则是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

个人理解：

            设计业务时：将类与类之间的依赖转化为接口之间的依赖，即面向接口编程，因为相对于细节的多变性，接口则相对稳定得多，接口去制定业务规范和契约，而不要去涉及任何操作和细节，这些操作和细节交给具体的实现类去完成。

这样做的优点：

          可以减少类间的耦合性，提高系统的稳定性，减少并行开发引起的风险（风险扩散），提高代码的可读性和可维护性。

          A依赖B、B依赖C、C依赖D...... 若是修改A中的某个方法，B中依赖A的那个方法也要相应的修改，同样的，C、D中的方法也都需要修改，这就是风险扩散。

四、里氏替换原则：

官方论述：

                  如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都换成o2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。

    里氏替换原则包含以下4层含义：

          1、子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。

          2、子类中可以增加自己特有的方法。

          3、当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。

          4、当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

个人理解：

          子类可以扩展父类的功能，但是不能改变父类原有的功能，尽量不用重载，不用重写，原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合，组合等关系代替。

这样做的优点：

          使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。

五、接口隔离原则

官方论述：

           客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上

个人理解：

           接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

这样做的优点：

           A、减少了继承接口时不必要的冗余空实现、使得业务框架更加规范

           B、依赖几个专用的接口要比依赖一个综合接口更灵活

           C、通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

          注：与单一职责原则的区别：

           单一职责针对的是职责，注重的是具体实现和细节；接口隔离原则针对的是接口的约束，更加注重整体框架的构建

六、迪米特法则

官方论述：

             一个对象应该对其他对象保持最少的了解。
            网上更易理解的定义：只与直接的朋友通信。

            首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

个人理解：

          就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，隐藏实现细节，对外提供方法给别人调用。

这样做的优点：

          降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系

    注意：迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。

          迪米特法则遵循是自己的就是自己的，如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中。

 

      不知不觉已经过了零点^_^#

    以上，便是设计模式要遵循的六大原则。主要参考书籍有《大话设计模式》以及网上一些零散的文章，但主要内容还是个人对这六个原则的感悟。这些原则对设计模式开篇系统地整理一下，一方面也与广大的网友分享，因为设计模式对编程人员来说，的确非常重要。如果大家对这六项原则有自己独到的见解，欢迎留言，大家共同探讨、共同进步@-@！