设计模式设计原则

编码中的设计模式很多，但都是紧紧围绕设计模式原则而演变的。提到设计模式原则，大多会提到一下六大设计原则（不止6种）：

1. 单一职责原则（Single Responsibility Principle）
2. 里氏替换原则（Liskov Substitution Principle）
3. 依赖倒置原则（Dependence Inversion Principle）
4. 接口隔离原则（Interface Segregation Principle）
5. 迪米特法则（Law Of Demeter）
6. 开闭原则（Open Close Principle）

单一职责：
       职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。

        需要注意：拆分粒度问题，拆的太细，类太多，不以维护

        类级别的职责、方法级别的职责，使用哪种，需要根据情况权衡。

里氏替换：
     定义：  所有引用基类的地方必须透明地使用其子类的对象。

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

    里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：
         子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法（核心）。
          子类中可以增加自己特有的方法。
          当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。（这俩点理解的不是很明白） 

 

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

 

   疑问：这样是否重载和重写就不应该存在？

依赖倒置：
    定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

    核心思想：面向接口编程

    编程注意点：
      低层模块尽量都要有抽象类或接口，或许俩者都有
      变量的声明类型尽量是抽象类或接口
      使用继承时遵循里氏替换原则

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

  问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
   解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

   原则：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少

注意点：

接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

迪米特法则（最小知道原则）：
     定义：一个对象应该对其他对象保持最少的了解。（只与直接的朋友通信）
   
    陌生的类最好不要作为局部变量的形式出现在类的内部。

    耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。

   疑问：局部变量不属于朋友，那很多业务都很难实现吧？

 

开闭原则：（核心）

  对扩展开放，对修改关闭。

 

  还有一点：多用组合、聚合，少用继承

   
 设计模式原则不是做到越遵守越完美，而是权衡各要素，做到一个度，就OK；而这个度需要自己去把握，不要死套原理，脱离现实。

 

说明：文章很多内容来自大牛总结，在此不一一列举，感谢他们的共享。

 参考：http://blog.csdn.net/zhengzhb/article/details/7278174

 

鼓励自己一步步努力坚持.................