OO设计原则

      程序可以分为健壮的程序（扩展性强&效率高&人性化）和虚弱的程序（扩展性弱&效率不高&很难操作）。那怎么做程序才健壮呢？遵循设计原则。 

原则的描述

      设计原则不像设计模式那么多，原则只有7个而已。。。如下：

单一职责原则(Single Responsibility Principle,SRP):

概念：就一个类而言，应该仅有一个引起他变化的原因。（把变与不变的东西分离开来）

适应场景：如一个动物类有运动和休息两个职责，如果运动||休息责需要修改动物类都要修改，这样就有两个引起动物类变化的原因。

实现模式例子：把动物类细分为动物运动类和动物休息类，这样不管是运动功能需要修改还是休息功能需要修改都不会影响到另外的功能。

优点：修改一个功能时对其他功能的影响降低。

缺点：过分地遵循单一职责原则会产生职责扩散（产生大量的类），不过可以用一个大管家来管理。

里氏替换原则(The Liskov Substitution Principle,LSP）:

概念：子类型必须能够替换掉它们的父类型，而功能不变；子类可以扩展父类的功能，但不改变父类原有的功能。（继承不要重写方法）

适应场景：动物类有体力属性和跑&进食两个方法，一个狮子类继承了动物类重写了进食方法，跑方法必须有体力才成运行，动物类的进食方法增加体力。但狮子类的进食没有增加体力。这狮子就跑不动了。。

实现模式例子：狮子类添加新的进食方法，而不是重写进食方法。

优点：扩展对原来的功能的影响会降低。

缺点：只能实现编译时多态，不能实现运行时多态。

依赖倒转原则（Dependency Inversion Principle ,DIP）:

概念：高层模块不应该依赖底层模块，两者都应依赖抽象；抽象不应依赖细节，细节应依赖抽象。（面向接口编程）

适应场景：肉类和人类，中国人类有吃的方法需要肉类作为参数。3天后中国人类都变成素食者，程序就实现不了。

实现模式例子：但如果原本吃方法的参数是食物抽象类就可以解决这个问题。新建一个菜类继承食物类，把食物作为吃方法的参数。就可以实现素食啦。。

优点：大大提高了程序的扩展性。

缺点：增加了抽象类和接口。其实个人感觉不是问题。

接口分离原则（Interface Segregation Principle, ISP）:

概念：应当为客户提供尽可能小的单独的接口，而不是大的总接口。（不能分得太小）

适应场景：接口1有10个功能，有AB两个类实现它。但B类只需要3个功能。

实现模式例子：把这3个功能写成一个接口，然后接口1继承这接口。这样B类就不用实现它不需要的功能。就是把接口的粒度放小。

优点：不需要编写多余的代码，这多余的代码肯能会导致程序出错。

缺点：和单一职责原则一样会产生职责扩散。

合成/聚合复用原则(Composition/Aggregation Reuse Principle,CARP):

概念：要尽量使用合成/聚合，而不是继承关系达到复用。（组合胜于继承）

适应场景：一个很多内容的A类，只想修改A类的一个内容不懂其他东西。

实现模式例子：新建一个B类。创建A类属性和相同的方法签名，在方法里调用相应的方法。（达：这种方法用于重构比较好）

优点：聚合不像继承那么复杂，也可以很好的扩展。

缺点：A类和B类的耦合度很高。

迪米特法则/最少知识原则（Law of Demeter/Least Knowledge principle，LKP）:

概念：一个软件实体应当与尽可能少的其它实体发生作用。(接口也算第三者)

适应场景：A类调用B类。（适合任何的解耦）

实现模式例子： 创建C类调用B类，A类调用C类。（B类创建实现一个接口）

优点：很好的解耦。

缺点：过度遵循此原则会有大量的第三者。

开-闭原则（Open Closed Principle, OCP）:

概念：软件模块（类，模块，函数等等）应该可以在不可修改的情况下扩展。（程序无法做到完全的关闭；但类可以做到，如后面说到的BaseDao。）

适应场景：任何场景。

实现模式例子：此原则跟前面的6种有所不同，此原则只是告诉我们要做到怎样，但没有说要怎样做。。此模式更像是前面6种原则的结果。如果能把握好前面的6种原则扩展性自然就会加强。

优点：程序的扩展性。

缺点：无法完全实现，

 

原则间的关系

       * LSP是DIP的基础，DIP是LSP的重要补充。

       *OCP与DIP是目标和手段的关系。OCP是目标, DIP是到达OCP的手段。DIP是对"抽象化"的最好规范；由于OCP依赖DIP，LSP是DIP的基础，所以LSP也是OCP基础。

       *ISP也是OCP的一个重要手段。

温情提示：除了OCP之外其他原则都要把握好“度”。