设计模式系列-面向对象设计原则

1 单一职责原则

定义：对一个类而言，应该只有一个引起它变化的原因。

理解： 一个类中应该是一组相关性很高的函数和数据的封装。

单一职责原则划分界线？怎么划分相同的职责。最大的问题就在于如何划分单一职责。具体的单一根据个人经验和业务逻辑而定但也有一些基本的指导原则，例如玩去哪不一样的功能就不应该放在一个类中，一个类应该是一组相关性很高的函数的封装，根据这一原则，可以不断审视自己的代码，根据具体的业务，功能，对类进行拆分。如果你使用单一职责原则，只是增加了应用的复杂性。我的建议是试着退一步，然后客观地审视代码。

2 开闭原则

定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。但软件需要变化时尽量通过扩展的方式实现变化，而不是修改已有的代码来实现。但现实中修改代码和扩展代码往往都是同时存在的。
该原则保证的是尽量减少对原有模块的影响，确保原有模块的正确性。基本原则是你应该力图写出你不需要每次需求一改变代码就要改变的代码。所以这个原则可以用继承和多态来实现。

3 里氏替换原则

定义：一个程序里面的对象应该可以被它的子类替换，而不改变程序的正确性。

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法（但不能改变父类的行为）。

4 依赖倒置原则

依赖倒置的几个关键点：
（1）高层模块不应该依赖低层模块，两者都应该依赖其抽象；
（2）抽象不应该依赖细节;
（3）细节应该依赖抽象；
所谓的高层模块就是调用端，低层模块就是具体的实现类，依赖倒置原则在java中的表现就是：模块间的依赖通过抽象发生，现实类不发生直接的依赖关系，其依赖关系通过抽象类和接口发生的。

5 接口隔离原则

定义：类之间的依赖关系应该建立在最小的接口上。

问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

6 迪米特原则（最少知识原则）

定义：一个对象应该对其他对象有最少的了解，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的public方法，我就调用这么多，其他的一概不关心。通俗的讲就是一个类对自己依赖的类知道的越少越好，也就是对于被依赖的类，向外公开的方法应该尽可能的少

迪米特法则强调了以下两点：

第一要义:从被依赖者的角度来说：只暴露应该暴露的方法或者属性，即在编写相关的类的时候确定方法/属性的权限

第二要义:从依赖者的角度来说，只依赖应该依赖的对象