设计模式学习笔记（一）——六大原则

一、单一职责原则

就一个类而言，应该仅有一个引起他变化的原因。

单一职责表达出的用意就是 “单一” 二字，把各个功能独立出来，让他们满足单一的职责。
对于类的划分，函数职责的划分，每个人的标准可能不同，但是它也有一些基本的原则，比如，两个完全不一样的功能就不能放在一个类中、一个类应该是一组相关性很高的函数、数据的封装。

二、开闭原则

软件中的对象（类、模块、函数等）对于扩展应该是开放的，但是对于修改应该是封闭的。

比如，对于一个缓存方法，我们设置让其使用内存缓存。但是由于又有其他需求，我们需要进行磁盘缓存，这时我们就又写了一个类，专门负责进行磁盘缓存，然后进行判断，根据用户需求进行缓存设置。但是，如果我们现在又需要一个内存磁盘双缓存呢？甚至以后会需要更多的缓存需求。

这时我们就需要使用开闭原则，对于缓存的设置，抽象成一接口，让我们的缓存类实现这个接口，那么我们就不需要修改对于缓存策略的设置方法。

开闭原则指导我们，应该尽量通过扩展的方式实现变化，而不是修改现有的代码。

三、里氏替换原则

所有引用父类的地方必须能够透明的使用其子类的对象。

里氏替换原则告诉我们，在软件中将一个基类对象替换成子类对象，程序将不会产生任何错误和异常。但是反过来就不行了，有子类出现的地方父类就未必能适应。

里氏替换原则是实现开闭原则的重要方式之一。

在运用里氏替换原则时，尽量把父类设计成抽象类或者接口，让子类继承父类或实现父接口，并实现父类声明的方法。运行时，子类实例替换父类实例。

总结为两个字：抽象

四、依赖倒置原则

高层模块不应该依赖底层模块，两者都应该依赖于抽象。抽象不该依赖于细节，细节应该依赖于抽象。

依赖倒置原则在Java语言中的体现就是模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖原则是通过接口或抽象产生的。

一句话概括就是面向接口编程，或面向抽象编程。

如果类与类直接依赖于细节，那么他们之间就有直接的耦合，当具体的需求变化时，就意味着同时需要修改依赖着的代码，这一定程度上限制了系统的扩展性。但是只要我们把依赖修改成抽象或者接口，那么我们就不用再修改依赖者的依赖细节代码。

五、接口隔离原则

一个类对另一个类的依赖应该建立在最小的接口上

建立单一接口，不要建立庞大臃肿的接口，将可能的细化接口，接口中的方法尽量少。不要试图建立一个很庞大的接口供所有依赖他的类调用。

六、迪米特原则

一个软件实体应当尽可能少的与其他实体发生相互作用

也称为最少知识原则，当一个模块发生修改时，就会尽量少的影响到其他模块。

迪米特原则要求我们在设计系统的时候，要尽量减少两个对象之间的交互，如果两个对象之间不需要彼此之间的通信，那么两个对象就不应该发生任何的直接相互作用。

如果需要调用一个对象的某一个方法，则可以通过第三者转发这个调用。简言之，添加一个第三者，减低现有对象的耦合度。