【设计模式】【1】 SOLID原则

SOLID原则

​ 对于是否真的有能够同时应用所有这五条原则的成功软件产品表示怀疑。有原则是件好事，但是也要时刻从实用的角度来 考量，不要把这里的每句话当作放之四海皆准的教条。

S：单一职责原则

修改一个类的原因只能有一个

尽量让每个类只负责软件中的一个功能，并将该功能完全封装（你也可称之为隐藏）在该类中。 这条原则的主要目的是减少复杂度。你不需要费尽心机地去 构思如何仅用 200 行代码来实现复杂设计，实际上完全可以 使用十几个清晰的方法。 当程序规模不断扩大、变更不断增加后，真实问题才会逐渐 显现出来。到了某个时候，类会变得过于庞大，以至于你无 法记住其细节。查找代码将变得非常缓慢，你必须浏览整个 类，甚至整个程序才能找到需要的东西。程序中实体的数量 会让你的大脑堆栈过载，你会感觉自己对代码失去了控制。 还有一点：如果类负责的东西太多，那么当其中任何一件事 发生改变时，你都必须对类进行修改。而在进行修改时，你 就有可能改动类中自己并不希望改动的部分。

O：开闭原则

对于扩展，类应该是“开放”的；对于修改，类则应 是“封闭”的。

本原则的主要理念是在实现新功能时能保持已有代码不变。 如果你可以对一个类进行扩展，可以创建它的子类并对其做 任何事情（如新增方法或成员变量、重写基类行为等），那 么它就是开放的。有些编程语言允许你通过特殊关键字（例 如 final ）来限制对于类的进一步扩展， 这样类就不再是 “开放”的了。如果某个类已做好了充分的准备并可供其他 类使用的话（即其接口已明确定义且以后不会修改），那么 该类就是封闭（你可以称之为完整）的。 我第一次知道这条原则时曾感到困惑，因为开和闭这两个字 听上去是互斥的。但根据这条原则，一个类可以同时是“开 放（对于扩展而言）”和“封闭（对于修改而言）”的。 如果一个类已经完成开发、测试和审核工作，而且属于某个 框架或者可被其他类的代码直接使用的话，对其代码进行修 改就是有风险的。你可以创建一个子类并重写原始类的部分 内容以完成不同的行为，而不是直接对原始类的代码进行修 改。这样你既可以达成自己的目标，但同时又无需修改已有 的原始类客户端。 这条原则并不能应用于所有对类进行的修改中。如果你发现 类中存在缺陷，直接对其进行修复即可，不要为它创建子类。 子类不应该对其父类的问题负责。

L：里氏替换原则

当你扩展一个类时， 记住你应该要能在不修改客户端 代码的情况下将子类的对象作为父类对象进行传递。

这意味着子类必须保持与父类行为的兼容。在重写一个方法 时，你要对基类行为进行扩展，而不是将其完全替换。 替换原则是用于预测子类是否与代码兼容，以及是否能与其 超类对象协作的一组检查。这一概念在开发程序库和框架时 非常重要，因为其中的类将会在他人的代码中使用——你是 无法直接访问和修改这些代码的。

I：接口隔离原则

客户端不应被强迫依赖于其不使用的方法。

尽量缩小接口的范围，使得客户端的类不必实现其不需要的 行为。 根据接口隔离原则，你必须将“臃肿”的方法拆分为多个颗 粒度更小的具体方法。客户端必须仅实现其实际需要的方法。 否则，对于“臃肿”接口的修改可能会导致程序出错，即使 客户端根本没有使用修改后的方法。

D：依赖倒置原则

高层次的类不应该依赖于低层次的类。 两者都应该依 赖于抽象接口。抽象接口不应依赖于具体实现。具体 实现应该依赖于抽象接口。

通常在设计软件时，你可以辨别出不同层次的类。

• 低层次的类实现基础操作（例如磁盘操作、传输网络数据和 连接数据库等）。

• 高层次类包含复杂业务逻辑以指导低层次类执行特定操作。