1.2.2  S.O.L.I.D.设计原则

S.O.L.I.D.设计原则是一组针对面向对象设计的最佳实践。GoF设计模式均以这样或那样的形式遵守这些原则。术语S.O.L.I.D.来自于Robert C. Martin(朋友们亲切地称呼他Bob大叔)的著作Agile Principles, Patterns, and Practices in C#中收集的5个设计原则的名称的首字母。下面将依次介绍这些设计原则。

1. 单一责任原则(SRP)

SRP原则与SoC原则保持高度一致。它要求每个对象只应该为一个元素而改变而且只有一个职责关注点。遵循这个原则，就可以避免单体类(就像是软件领域的瑞士军刀)设计问题。使每个类均保持简洁，就可以提升系统的可读性和可维护性。

2. 开放封闭原则(OCP)

OCP原则要求类对于扩展应该是开放的，而对于修改应该是封闭的，这样应该就能够在不改变类的内部行为的情况下添加新功能并扩展类。这个原则努力避免破坏已有的类以及其他依赖它的类，因为这会在应用程序中造成bug和错误的涟漪效应。

3. 里氏替换原则(LSP)

LSP原则指出应该能够使用任何继承类来替代父类并且让其行为方式保持不变。这个原则与OCP原则保持一致：它确保继承类不会影响父类的行为，换句话来说，继承类必须可替代它们的基类。

4. 接口分离原则(ISP)

ISP原则关注的是将契约的方法划分成若干职责分组，并且为这些分组指派不同的接口，这样客户端就不需要实现一个庞大的接口和一堆它们并不使用的方法。这个原则背后的目的是：使用相同接口的类只需要实现特定的一组方法，而不是实现一个庞大的单体方法接口。

5. 依赖倒置原则(DIP)

DIP原则的宗旨是将自己编写的类与具体的实现隔离开来，让这些类依赖于抽象类或接口。它提倡面向接口(而不是实现)编程，这确保代码不会与某种实现紧密耦合，从而提高了系统的灵活性。

6. 依赖注入(DI)和控制反转(IoC)原则

与DIP紧密相关的是DI原则和IoC原则。DI通过构造器、方法或属性来提供底层类或从属类。配合使用DI原则，这些从属类可以被反转为接口或抽象类，这样就可以形成一个具有较高的可测试性和易于修改的松散耦合系统。

在IoC原则中，系统的控制流与过程式编程方法相比是反转的。这个原则的一个示例是IoC容器，它的作用是将服务注入到客户端代码，而不必让客户端代码指定具体的实现。在该实例中，控制反转指的是客户端获取服务的行为。

本书中，将更详细地研究每个S.O.L.I.D.原则。但接下来，将探讨一些专门用来处理特殊情况的企业级模式，它们以常见设计原则和设计模式为基础构建。