设计模式的六大原则

一、单一职责原则

单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。

---

我们在编程的时候，很自然的就会给一个类增加各种各样的功能，比如一个Fun类中，可能包含了各种各样的代码，像一些运算的算法、数据库访问的SQL语句什么的，但如果这样做就意味着，无论任何需求的改变，都需要对Fun类进行更改，维护麻烦，复用不可能，也缺乏灵活性。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。事实上，完全对每个功能进行划分，把一个类划分称多个类。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
如果能想到多于一个的动机去改变一个类，那么这个类就具有多于一个类的职责。
做到单一职责，这样代码才是真正的易维护、易扩展、易复用、灵活多样。

二、开放封闭原则

开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。

---

开放封闭原则有两个特征，一个是对于扩展是开放的，另一个是对于更改是封闭的

我们在做任何系统的时候，都不要指望系统一开始的需求确定就再也不会变化，这是不显示也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计的软件可以相对容易修改，不至于说，新需求以来，就要把整个程序推到重来。怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？开放封闭给了我们答案。

开放封闭原则的意思就是说，设计的时候，时刻要考虑，尽量让这个类足够好，写好了就不要去修改了，如果新的需求来了，我们增加一些类就完事了，原来的代码能不动就不动。但是绝对的修改关闭是不可能的。无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪些变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。
但是如果猜测的方向有误，就会把本该简单的设计做的非常复杂，很不划算，而且事先预测又是很难做到的。但我们可以在发生小变化的时候，就及早去想办法应对发生更大变化的可能。也就是说等到变化发生时立即采取行动。在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后可能发生的同类变化。 面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

当然，并不是什么时候应对变化都是容易的。我们希望的是在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。 比如一个类在很多地方都运用了，再考虑抽象、分离就很困难。

开放封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象，然而，对于应用程序中每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

三、依赖倒转原则

依赖倒转原则
1.高层模块不应该依赖底层模块。两个都应该依赖对象。
2.抽象不应该依赖细节。细节应该依赖抽象。

---

抽象不应该依赖细节，细节应该依赖于对象，说白了就是要针对接口编程，不要对实现编程。比如电脑的主板、CPU、内存、硬盘都是在针对接口设计的，内存不够只要插槽足够就可以添加，硬盘不够可以用移动硬盘等，PC的接口是有限的，所以扩展有限，软件系统设计得好，却可以无限地扩展。如果主板、CPU、内存、硬盘针对实现来设计，内存就要对应到具体的某个品牌的主板，那就会出现换内存需要把主板也换了的尴尬。

就比如，我们在做项目的时候，大多要访问数据库，所以我们就把访问数据库的代码写成了函数，每次做新项目的时候就去调用这些函数。这就叫高层模块依赖了低层模块。
看起来没问题，但是这些高层模块的业务逻辑都是一样的，如果客户希望用不同的数据库或存储信息方式，这时就出现麻烦了，我们不能很好的复用这些高层模块，因为它和低层的访问数据库绑定在一起，这就非常糟糕了。
但是如果让高层模块和低层模块都依赖于抽象，定义一个抽象类，让低层模块实现该抽象类，并且让高层模块调用抽象类，如果客户更改需求，要求使用不同的数据库，那我们只需要在抽象类的基础上扩展一个访问新的数据库的低层模块或者对原来的低层模块进行修改，就可以很好的复用高层模块，基本不用做更改。
两者的UML图对比：

依赖倒转原则其实可以说时面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化的设计了。

那么可能就会有人问了，为什么依赖了接口或者抽象就不怕更改呢？扩展出来的低层模块就一定可以满足要求吗？
这就需要来讲另一个原则了——里氏代换原则

四、里氏代换原则

里氏代换原则：子类型必须能替换掉它们的夫类型。

---

里氏代换原则的意思就是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化，简单点说，子类型必须能替换掉它们的夫类型。

就比如，现在有两个类，一个鸟类，一个企鹅类，如果鸟是可以飞的，企鹅不会飞，企鹅类就不能继承鸟类。因为子类应该拥有父类所有非private的属性和行为，虽然生物学分类上企鹅也是一种鸟，但是在编程世界里，企鹅不能以父类——鸟类的身份出现，因为企鹅不能飞，而鸟能飞。

只有当子类可以替换掉父类，软件单位的功能不受影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。正是由于子类型的可替换性才使得 使用父类类型 的模块在无需修改的情况下就可以扩展。

五、迪米特法则

迪米特法则，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

---

迪米特法则首先强调的前提时在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。如果需要公开的字段，通常就用属性来体现了。

迪米特法则其根本思想，是强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类如果被修改，不会对有关系的类造成波及。也就是说信息的储藏促进了软件的复用。

六、接口隔离原则（了解不多，引用百度百科）

接口隔离原则，客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。

---

使用多个专门的接口比使用单一的总接口要好。

一个类对另外一个类的依赖性应当是建立在最小的接口上的。

一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

---

设计模式的六大原则对学习设计模式有很大的帮助，建议学习设计模式前先学习设计模式的六大原则。