设计模式之设计原则

在产品的开发迭代中，需求修改是经常遇到的，一旦需求改变了，那么程序代码也需要跟着做出相应的调整，在程序开发中前人总结出了几个设计原则来应对这种变化，基于这几种原则来进行程序设计能够更加快速、安全去应对各种变化。

设计原则目的

• 将变化和不变分离，尽量降低变化的可能，缩小变化的影响范围，使模块、类、方法尽量原子化
• 扩展的时候，尽量新增类，而不是修改原有的类

一、单一职责原则 Single Responsibility Principle

永远不要让一个类存在多个改变的理由。尽量降低变化的可能

二、开闭原则 Open Closed Principle

软件实体应当对扩展开放，对修改关闭，尽量保证原有逻辑的正确性,降低影响范围

• 抽离逻辑骨架，定义为接口，接口是稳定的，具体的细节可以通过添加实现类来扩展。
• 直接提供一套新的接口及实现

三、里氏替换原则 Liskov Substitution Principle

任何时候都可以用子类型替换掉父类型。 里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。最终目的就是为了实现开闭原则。

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类中可以增加自己特有的方法。
• 当子类的方法重载父类的方法时，子类方法的参数要是父类方法参数的父类。
• 当子类的方法实现父类的抽象方法时，方法的返回值要是父类的返回值的子类。
• 如果非要重写父类的方法，比较通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合，组合等关系代替。

四、迪米特法则(最少知识原则) Law of Demeter

降低相互依赖，一个对象应当对其他对象有尽可能少的依赖，降低依赖对象改变引起其他的对象的改动

• 门面模式和中介者模式
• 在写类的时候，能不 public 就不 public ，所有暴露的属性或是接口，都是不得不暴露的，保证其他类对这个类有最少的了解了
• 单一职责原则和接口隔离原则

五、接口隔离原则 Interface Segregation Principle

尽量保证接口中只有用户关心的方法，避免用户去实现不关心的接口。将接口的粒度控制到最小，这样以后修改的可能就会更小

• 如果一个类实现一个接口，但这个接口中有它不需要的方法，那么就需要把这个接口拆分，把它需要的方法提取出来，组成一个新的接口让这个类去实现，这就是接口隔离原则
• 提高内聚，减少对外交互，如果用户实现了不关心的接口方法，如果方法发生变化，导致用户也需跟着改动
• 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不争的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
• 看起来，该原则与单一职责原则很相像。确实很像，二者都是强调要将接口进行细分，只不过分的方式不同。单一职责原则是按照 职责 进行划分接口的；而接口隔离原则则是按照实现类对方法的使用来划分的。可以说，接口隔离原则更细一些。

六、依赖倒转原则 Dependence Inversion Principle

抽象不应该依赖细节，细节应该依赖抽象，面向接口编程。依赖不变的，不要依赖变动的

• 依赖抽象，当需要改变细节时，只需要再添加一种新的实现类，然后将依赖修改为新的实现类对象

• 在开发中，经常会定义很多接口，然后写一种实现，虽然很多时候只有一种实现，但是谁能保证会不会再多出一种实现，一旦需要修改细节实现，只需要添加一种实现类，如 Dao层，可以提供多种数据来源的具体实现，Service层只需要依赖Dao提供的接口，接口时不会变的。

设计模式

为了更好的是遵循和实现设计原则，前人总结了一些设计模式

image