设计对象的一些基本原则(学习自设计模式之禅)

1.单一职责原则(srp):就是设计一个对象,对象的职责要单一.

比如设计用户类,将用户的行为和用户的属性分成两个接口,继承的方式设计类.

还有一个srp的解释是:there is no more than one reason for a class to change

但srp的原则有可能把握的过细，导致类太散。所以也不可以走极端。

 

2.里式替换原则：代码中使用父类的地方都可以用他的子类来代替。

 个人理解，子类里有全部的父类的方法（继承来的或者重载过了），若重载了方法，实现的逻辑肯定和父类不一样。所以实现的结果和父类类似，但具体的实现过程由子类自己确定。 如果出现方法无法实现父类的业务逻辑，就不能继承。

   注意点: 

   1.子类的方法和父类一样，入参B是父类的入参A的子类，用A，B作为入参调用父类。

   2.子类的方法和父类一样，入参A是父类的入参B的父类，用A为入参调用子类，用B作为入参调用父类的方法。

   3.子类重载父类时，返回值可以是父类返回值的子类。

 

3.依赖倒置原则：高层模块不应该依赖于底层模块,而是依赖于它的抽象.

                      抽象不应该依赖于细节,细节应该依赖于抽象

自己理解: 高层类在使用底层类时,使用底层类的抽象(接口),这样就可以操作继承于这个抽象(接口)的所有类了.

细节依赖于抽象也是便于调用时用抽象可以调用细节.

 

4.接口隔离原则:客户端不应该依赖于不需要的接口 ，类间的依赖关系应该建立在最小的接口上。

个人理解 ： 类实现接口时，需要实现此接口的所有方法，故接口不可臃肿，接口的定义就是某个原子功能 。类通过实现多个接口来拼成类的所有实现功能 。接口应该尽量原子性。

 

5.迪米特法则：也称最少知识法则，一个对象对其他对象应该有最少的了解。

1.只和朋友类交流 （朋友类指的是有组合聚合依赖关系的类）

2.保持类的松耦合，不可把自己类的整合实现逻辑放到其他类里，这样类的函数变动会导致其他类的大变（不过service掉dao层方法就是整合dao层原子方法实现业务逻辑，dao层的方法变动对service层影响很大）

3.一个方法放在本类中如果不增加类的关系，也不对类产生负面影响，就放在本类中

4.谨慎使用seriallzable 接口 ，防止调用方法的两端不一致导致出错 。

 

6.开闭原则 ： 对扩展开放，对修改关闭。

简单理解就是需求变动时，尽量扩展，不能直接修改原来的功能 。扩展可以通过继承原来的类，复写需要修改的方法来实现。

好处：便于测试，复用原来的代码，便于维护，符合面向对象的 思想

使用方法：设计抽象，扩展的类基于抽象，所以抽象需要保持稳定。使用元数据（可以通过xml等配置的方法），灵活拼装业务类的实现。规范的章程。封装变化。