在21世纪的前几年里，“Uncle Bob”Robert Martin引入了用OOP开发软件的五条原
则，其目的是设计出更易于维护的高质量系统。无论是设计新应用程序，还是重构现有基
本代码，这些SOLID原则都成为开发人员的地图。
一 单一职责原则
单一职责原则(Single Responsibility Principle，SRP)指出，每个方法或类应当有且仅有
一个改变的理由。这意味着每个方法或类应当做一件事情，或者只有一项职责。在所有的
SOLID原则中，这是大多数开发人员感到最能完全理解的一条。严格来说，这也可能是违
反最频繁的一条原则了。
二 开放闭合原则
开放/封闭原则(Open/Close Principle，OCP)是指软件(方法、类等)应当开放扩充且关闭
修改。如果觉得它非常类似于继承的OOP 原则，那就对了。它们之间的关系非常密切。事
实上，在.NET中OCP就是依赖于继承的。
OCP的要点在于：作为开发人员，别人偶尔会向我们提供基类，偶尔也会为其他开发人
员生成基类框架，供其使用。这些使用者应当仅能使用这些基类，但不能对其进行修改。
这一点是必要的，因为其他使用者也可能依赖于由基类提供的功能。如果允许使用者修改
这些基类，可能会导致连锁反应，不仅会影响到应用程序中的各方面，还会影响到企业内
的应用程序。还有一个问题，使用者有时可能会收到基类的升级版本。使用者在升级之前，
必须找出一种方法用来处理其对该基类先前版本中所做的自定义。
于是，问题变为：“那么，如果我需要修改这个基类的工作方式，那应当怎么做呢？”
OCP的另一部分中给出这一答案；基类应当开放，可进行扩充。在这里，扩充是指创建一
个由此基类继承而来的派生类，它可以扩充或重载基类功能，以提供使用者所需要的特定
功能。这样，使用者就能使用类的修改版本，而不会影响到类的其他使用者。使用者还可
以在将来更轻松地使用基类的升级版本，因为他们不用担心丢失自己的修改内容。
三 里氏代换原则
继承对于OCP，就相当于多态性对于里氏替换原则(Liskov Substitution Principle，LSP)。
LSP 规定：用超类代替应用程序中使用的对象时，应当不会破坏应用程序。这通常也被称
为“契约式设计(design by contract)”。
回想前面的多态性示例，ComputePay 方法使用了Employee 类型的列表，其中Employee
就是基类型(超类型)。Salary、Hourly 和Seasonal 类都是从Employee 继承而来，因此它们
是Employee 的子类型。
根据LSP，即使已经将列表声明为Employee 的列表，也仍然可以用Salary、Hourly
和Seasonal 的具体实例来填充它。因为有了继承，它们都支持Employee 声明的相同契约(公
共的方法集或API)。应用程序可以对该列表进行迭代，并调用那些在列表中各个项目的
Employee 上定义的方法，不需要知道或特别关心它们都是什么类型。如果它们支持契约，
该调用就是合法的。
四 接口分离原则
到目前为止，已经在示例中使用了基于类的继承，但还没有过多地讨论接口。回想一
下，接口就是在代码中定义的契约，而类同意实现这一契约。这份协议要求类来为接口中
定义的所有方法提供实现。至于如何实现方法，则由这个类来决定，只要它遵守契约，支
持接口中的定义即可。接口是.NET中功能非常强大的功能；它们对继承和多态的支持方式
与类相同。
接口分离原则(Interface Segregation Principle，ISP)规定，不应当强制客户端依赖于其
不使用的接口。例如，银行系统可能有一个用于评估信用申请的服务。为便于讨论，假定
该服务不仅处理有质押信用(车船贷款、抵押)，也处理无质押信用(信用卡、信用证、股票
信用额度)。如果正在开发一个客户端，用于帮助从事汽车代理的金融专员为其客户获得汽
车贷款，则只需要关注汽车贷款的申请即可，无需考虑有关这一服务的任何其他事情。如
果没有ISP，应用程序可能必须了解其他方法。
尽管乍看起来这并没有什么，但它至少是增加了应用程序的复杂性，因为据以进行开
发的API中会有许多方法，远远超出所需要的。这样可能会导致混淆，调用错误的方法还
可能会导致潜在的错误。还有一种可能，API中未被应用程序用到的部分可能会改变，而
这又会导致对终端的改变。这样，因为没用到、没想用、甚至是根本就不关心的一些功能，
而增加了应用程序的维护成本。这种情况还存在安全风险。该应用程序是专用于汽车贷款
的。如果不道德的开发人员利用这个过于庞大的API来允许利用这一申请担保其他类型的
信用，又该怎么办呢？这种问题的严重性就不仅仅是代码瘫痪、不可维护那么简单了。
这一问题的解决方案就是专门针对客户端的需要，为该服务创建几个更小的、更精细
的接口。对于该示例应用程序，专门设计一个针对汽车贷款的接口是比较适当的做法。应
用程序可以用同一实现访问同一个类，但这一次它使用了一个特定的接口，其中仅有实际
服务的一部分方法。这样就降低了复杂性，将应用程序与API其他部分的修改隔离开来，
还有助于堵塞安全漏洞。
五 依赖倒转原则
在完美世界里，应用程序的组件之间没有耦合关系或绑定关系。开发人员也能够改变
自己希望改变的任何东西，而不需要担心在应用程序的其他地方出现缺陷，或者“不希望
存在的负面影响”。令人悲伤的是，我们并不是生活在完美世界里。因此，组件需要相互
绑定在一起，或者在某一点耦合，以构成实际应用程序。
依赖倒置原则(Dependency Inversion Principle，DIP)规定：代码应当取决于抽象概念，
而不是具体实现；这些抽象不应当依赖于细节；而细节应当依赖于抽象。类可能依赖于其
他类来执行其工作(Employee 服务可能依赖于数据访问组件向数据存储中保存和检索员工
信息)。但是，它们不应当依赖于该类的特定具体实现，而应当是它的抽象。也就是说，
Employee 服务不知道(或不关心)正在使用哪个具体的数据访问组件——只有它的抽象或代
码契约(或接口)支持那些用于保存和检索员工所需要的方法。
显然，这一概念会大大提高系统的灵活性。如果类只关心它们用于支持特定契约而不
是特定类型的组件，就可以快速而轻松地修改这些低级服务的功能，同时最大限度地降低
对系统其余部分的影响。在第6 章，还会看到如何利用这一概念来模拟这些依赖项，以进
行测试。有时，需要向类中提供这一低级服务的具体实现，以便这个类能够完成自己的工
作。最常见的做法，特别是在.NET中使用TDD 的开发人员，就是依赖项注入(DI)模式。
＝＝＝＝＝＝＝＝＝＝＝＝以上OOP软件设计的SOLID原则＝＝＝＝＝＝＝＝＝＝＝＝＝＝
控制反转原则
全局注册树
ORM 对象数据映射
合成聚合原则
启动和执行分离原则
面向接口编程
配置加载 不是硬编程原则
