引言

首先我们由一个实际问题来引出抽象工厂模式。

考虑这样一个场景，系统中需要向OSS上传文件，以及通过OSS下载文件。而在系统中有不同的业务在使用这两个功能。如下图：

定义

Clients should not be forced to depend upon interfaces that they don’t use.
客户端不应该依赖那些它不需要的接口

核心思想

记得几年前有一位很厉害的前辈说过：软件设计是什么，就是“分离关注点，消除重复”。这句话一直影响这我，而我做软件设计也是朝着这两个方向努力。而接口隔离原则最核心的就是拆分，即分离关注点。

定义

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.

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

简而言之就是“面向接口编程”。

定义

里氏替换原则是Barbara Liskov^[1]与1988年提出来的。原文是：

What is wanted here is something like the following substitution property: If for each object of type S there is an object of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when is substituted for then S is a subtype of T

如果对每一个类型为$S$的对象$O_1$， 都有类型为$T$的对象$O_2$， 使得以T定义的所有程序P在所有的对象$O_1$都代换成$O_2$时， 程序 P 的行为没有发生变化， 那么类型$S$是类型$T$的子类型。

另一种说法是：

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

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

定义

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。

核心思想

开闭原则的核心思想就是抽象。开闭原则的主要目的就是为了让我们在不修改源码的情况下来扩展系统的功能。

核心思想

定义

A class should have only one reason to change. （ 就一个类而言，应该仅有一个引起它变化的原因）

每一个职责都是变化的一个轴线（an axis of change）。当需求变化时，该变化会反映为类的职责变化。如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。

如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生是，设计会遭到意想不到的破坏。

引用自：《Agile Software Development, Principles, Patterns, and Practices》

关于这句话中的 “类的变化” 是指什么，书中并没有给出明确的说明。从字面上来理解的话应该是指类的代码的修改。

那么单一职责的作用是什么呢？我认为主要有以下几点：

1. 降低类的复杂度
2. 使代码的可读性和可维护性提高。
3. 降低业务的耦合度，使某项业务修改时只需要关注一个点，而不是整个业务链。（后面举例说明）