设计模式之原则篇

单一职责原则

定义上来说：应该有且仅有一个原因引起类的变更。

单一职责原则为我们提供了一个编写程序的准则，要求程序员在写代码（类，抽象类，接口）的时候，要使其功能职责单一纯粹，使其改变的外在因素缩减到最少。

从另一个方面来说，如果一个功能（类）承担的职责过多，相当于把这些职责耦合在一起。当其中一个职责改变时，可能会会牵一发而动全身，从而造成这个功能（类）失效，不利于持续改进。

打一个例子，就用调味剂来说，盐是咸的，还有一种椒盐，也是咸的，但是里边有一些其他调味剂，在炒菜的时候我们会放盐，但是在调菜的时候我们一般会放椒盐，因为椒盐更美味。如果我们不管是炒菜还是调菜都放盐，那么调菜会口感差一些，如果都放椒盐，那么炒菜会口感差一些。在专用之后，从某方面提升了品质。这也可以说是职业化带来的好处。

在说的过程中我突然想到了一个历史上的非常符合单一职责原则的常识。不管在哪个朝代，都有军队，但是军队的形式一直都是在变化的，在三国时期其中是最明显的，有专业化军队（单一职责），也有军农互转的战时为兵，休时为农的屯田兵。在这两种军队对比的时候，往往会被专业化军队一比三甚至一比五的打败。另一方面，专业化军队如果战力为1，那么屯田兵也就只有0.5，当两个军队合并时战力不是为1.5，而是因为两者的不匹配造成战力下降，成了0.7，那么因为其中一方的变化会造成这个战力值的不断改变，甚至降至冰点。

开放-封闭原则

定义：软件实体应该允许扩充，但禁止修改。

”对于扩展是开放的。“ 这意味着模块的行为是可以扩展的。当应用程序的需求改变时，我们可以对其模块进行扩展，使其具有满足那些需求变更的新行为。换句话说，我们可以改变模块的功能。

“对于修改是封闭的。“ 对模块行为进行扩展时，不必改动该模块的源代码或二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或Java的.jar文件，都无需改动。

当然，不管是什么都离不了意外：

1.修复缺陷所做的改动

缺陷在软件中很常见，是不可能完全消除的。当缺陷出现时，就需要我们修复现有的代码。软件修复明显倾向于实用主义而不是坚持开放封闭原则。

2.客户端无法感知到的改动

这两样是需要改动的，也是必须改动的。

依赖倒转原则

定义：程序依赖于抽象接口，不要依赖于具体实现。

简单的来说，就是对抽象类进行编程，对于现实类就不要动了，这样可以降低客户与实现模块间的耦合。

在这里，有两点是要遵守的：

1.抽象不应该依赖于细节，细节应该依赖于抽象。

2.高层模块不依赖底层模块，两者都依赖抽象。

从大话模式中用的是电脑主机来说明的。从本质上讲，主板，内存条，硬盘，显卡等是互相依存的，缺少了其中任意一个，电脑都是不可使用的，但是当其中一个坏掉后，直接更换坏掉的那个件，就可以再次使用。虽然是必不可少的一部分，但是当坏掉后，我们可以快速更换后继续使用，这点就是符合依赖倒转原则的。我们依赖于此，但是你是可以替换的。