23种设计模式（0）之面向对象设计的八大原则

依赖倒置原则（DIP）

心思想：客户端代码(调用的类)尽量依赖(使用)抽象的组件。抽象的是稳定的。实现是多变的。

依赖倒置原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类

使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。

为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。

在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统的功能，满足开闭原则的要求。

我们需要针对抽象层编程，而将具体类的对象通过依赖注入的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象来覆盖父类对象。

开放封闭原则（OCP）

核心思想：对扩展开放，对修改关闭。增加新功能，不改变原有代码。

在软件系统开发过程中，软件的需求往往会随着时间的推移而发生变化。因此，进行软件设计时需要考虑怎样的设计才能面对需求的改变却可以相对保持稳定，从而使得系统可以在第一个版本以后不断推出新的版本。如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行扩展，而且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。

为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。在进行软件设计时，一般先评估出最有可能发生变化的类，然后构造抽象来隔离那些变化。当变化发生时，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

单一职责原则（SRP）

 

核心思想：一个类有且只有一个改变它的原因。适用于基础类，不适用基于基础类构建复杂的聚合类。

一个类不要负责太多“杂乱”的工作。在软件系统中，如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时设计或遭受到意想不到的破坏。

以项目开发为例，如果项目组成员每个人的职责都很明确，可以专心开发自己负责的模块，则项目成果的质量往往很高。相反，如果职责不清晰，分工就会混乱，极有可能出现A负责N个模块，而B则可以在一旁开心地打酱油的情况。这样，如果A所负责的模块中有多个模块集中暴露问题时，A就很难高质量地将问题从容解决。

自己负责领域的事情都做，不是自己领域的事不去插手。

实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则。需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。

组合复用原则CRP

核心思想：如果仅仅为了代码复用优先选择组合复用，而非继承复用。组合的耦合性相对继承低。尽量使用对象组合，而不是继承来达到复用的目的。

在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能的目的。

首先应该考虑使用组合/聚合，组合/聚合可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少

其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。

通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白箱”复用，如果基类发生改变，那么子类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；而且继承只能在有限的环境中使用（如类没有声明为不能被继承）。

由于组合或聚合关系可以将已有的对象（也可称为成员对象）纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现细节对于新对象不可见，所以这种复用又称为“黑箱”复用，相对继承关系而言，其耦合度相对较低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作；合成复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。

里氏替换原则LSP

核心思想：父类出现的地方可以被子类替换，在替换后依然保持原功能。子类要拥有父类的所有功能。子类在重写父类方法时，尽量选择扩展重写，防止改变了功能。

(1)子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。

(2)尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，从而可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。是开闭原则的具体实现手段之一。

接口隔离原则ISP

核心思想：尽量定义小而精的接口interface，少定义大而全的接口。本质与单一职责相同。小接口之间功能隔离，实现类需要多个功能时可以选择多实现.或接口之间做继承。

使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。

每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干，使接口的职责明确。

在面向对象编程语言中，实现一个接口就需要实现该接口中定义的所有方法。因此如果接口方法过多，其实现类中就不得不去处理许多自己根本不需要的方法。故大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便，并都承担某一单一角色。

面向接口编程而非面向实现

核心思想：客户端通过一系列抽象操作实例，而无需关注具体类型。

便于灵活切换一系列功能。实现软件的并行开发。

迪米特法则LOD

核心思想：类与类交互时，在满足功能要求的基础上，传递的数据量越少越好。因为这样可能降低耦合度。

一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

通过引入一个合理的第三者来降低现有对象之间的耦合度。

在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。