zp_bj04
OO设计原则是根本，设计模式是设计原则在具体问题中的应用。本文将尝试汇总究竟有哪些OO设计原则，以及它们之间的内在联系。
首先不得不提著名的SOLID原则：Single responsibility, Open closed, Liskov substitution, Interface segregation, Dependency inversion。
单一责任原则SRP（Single Responsibility Principle）：一个类/对象只有一个引起变化的原因。换言之，一个类只有一个类型责任。
开放封闭原则OCP（Open Closed Principle）：软件实体对扩展开放，对修改封闭。
里氏替换原则LSP（Liskov Substitution Principle）：子类的实例能够替换其父类的实例。
接口分离原则ISP（Interface Segregation Principle）：使用多个专门的接口比使用单一的总接口要好。一个类对另一个的依赖性建立在最小的接口上。
依赖倒置原则DIP（Dependency Inversion Principle）：依赖抽象不要依赖具体实现。
单一责任原则SRP（Single Responsibility Principle）：一个类/对象只有一个引起变化的原因。换言之，一个类只有一个类型责任。
开放封闭原则OCP（Open Closed Principle）：软件实体对扩展开放，对修改封闭。
里氏替换原则LSP（Liskov Substitution Principle）：子类的实例能够替换其父类的实例。
接口分离原则ISP（Interface Segregation Principle）：使用多个专门的接口比使用单一的总接口要好。一个类对另一个的依赖性建立在最小的接口上。
依赖倒置原则DIP（Dependency Inversion Principle）：依赖抽象不要依赖具体实现。
封装变化原则：把会变化的部分独立出来，让其他部分不受影响。
组合复用原则：优先使用组合而不是继承，通过获得对其他对象的引用而在运行时刻动态改变对象行为。
组合复用原则：优先使用组合而不是继承，通过获得对其他对象的引用而在运行时刻动态改变对象行为。
迪米特法则LoD（Law of Demeter）：也称为最少知识原则LKP（Least Knowledge Principle），一个对象应该对其他对象有最少的了解。
其它OO设计原则：
松耦合原则：对象之间的依赖尽量的少。
松耦合原则：对象之间的依赖尽量的少。
好莱坞原则：别调用我们，我们会调用你。
针对接口编程而不是实现：依赖抽象类的接口，可以在运行时改变对象行为，也就是多态。
针对接口编程而不是实现：依赖抽象类的接口，可以在运行时改变对象行为，也就是多态。
DRY原则（Don't repeat yourself）：避免重复的代码，这样会降低可维护性。
看到这么多设计原则可能会有些头晕，就像小时候妈妈教我们的做人大道理，宽泛而很难体会，没有经验的工程师只能把他们背下来，在以后的实践过程中慢慢体会。我
们可以初步分析一下这些原则的内在联系。
其中DRY原则和松耦合原则，是所有原则的基础，不仅是OO设计的根本，也是所有软件设计的灵魂，我们暂且不归为OO设计原则，应该作为公理存在潜意识中，就像”你
要做个好人“。
封装变化原则，目的是为了提高代码的可维护性，就面向对象设计而言，开放封闭原则就包含了封装变化原则，不仅包含了，跟进一步用扩展的方法来约束变化，所以该
原则可以纳入开放封闭原则。
针对接口编程而不是实现与依赖倒置原则很相似，可以说是同一原则的着眼点不同，针对接口编程原则强调的是接口的客户，接口使用者不用关心接口的具体实现；依赖
倒置原则强调的是高层模块与底层模块的依赖关系。其实二者是一个原则。
好莱坞原则是依赖倒置原则在框架设计中的一种技巧，可以不作为一个单独的原则。
经过萃取，我们留下了七大面向对象设计原则，他们是：单一责任原则、开放封闭原则、里氏替换原则、接口分离原则、依赖倒置原则、组合复用原则、迪米特法则。
在后面的学习中，我们可以具体分析每种设计模式应用了哪些设计原则。
一、单一职责原则（ＳＲＰ）
就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。
二、开闭原则（ＯＣＰ）
软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说：对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它的行为呢？
怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向
对象设计的方法，是软件工程设计方法的重要原则之一。
三、替换原则（ＬＳＰ）
子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计) 的概念推出。
四、依赖倒置原则（ＤＩＰ）
１、高层模块不应该依赖于低层模块。二者都应该依赖于抽象。２、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖
接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层的模块是对高层抽象模
块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化
方法的一个\"硬伤\"。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。
五、接口分离原则（ＩＳＰ）
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。 ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植
性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。
以上五个原则是面向对象中常常用到的原则。此外，除上述五原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化（一个类对应一个具体职责）等可供
我们在进行面向对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。
---------------------------------------------------------------------------------------------------------
(36)继承只应被用来为特化层次结构建模。
(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。
(38)基类中的所有数据都应当是私有的，不要使用保护数据。
类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。
(39)在理论上，继承层次体系应当深一点，越深越好。
(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。
(41)所有的抽象类都应当是基类。
(42)所有的基类都应当是抽象类。
(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。
(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。
(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。
(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。
(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。
(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。
(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。
(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。
(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。
(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。
(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。
(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。
(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。
(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？
(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。
(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。
(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。
“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”
----------摘抄自《OOD 启思录》--Arthur J.Riel 著 鲍志云 译
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类
中。
(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。
(22)尽量减少类的协作者的数量。
一个类用到的其他类的数目应当尽量少。
(23)尽量减少类和协作者之间传递的消息的数量。
(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。
(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。
(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。
(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。
(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。
当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。
(29)让系统功能在窄而深的继承体系中垂直分布。
(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。
(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。
(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。
(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。
(34)类必须知道它包含什么，但是不能知道谁包含它。
(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。
一、单一职责原则（ＳＲＰ）
就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。
二、开闭原则（ＯＣＰ）
软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说：对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它的行为呢？
怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向
对象设计的方法，是软件工程设计方法的重要原则之一。
三、替换原则（ＬＳＰ）
子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计) 的概念推出。
四、依赖倒置原则（ＤＩＰ）
１、高层模块不应该依赖于低层模块。二者都应该依赖于抽象。２、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖
接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层的模块是对高层抽象模
块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化
方法的一个\"硬伤\"。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。
五、接口分离原则（ＩＳＰ）
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。 ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植
性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。
以上五个原则是面向对象中常常用到的原则。此外，除上述五原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化（一个类对应一个具体职责）等可供
我们在进行面向对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。
---------------------------------------------------------------------------------------------------------
(36)继承只应被用来为特化层次结构建模。
(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。
(38)基类中的所有数据都应当是私有的，不要使用保护数据。
类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。
(39)在理论上，继承层次体系应当深一点，越深越好。
(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。
(41)所有的抽象类都应当是基类。
(42)所有的基类都应当是抽象类。
(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。
(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。
(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。
(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。
(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。
(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。
(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。
(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。
(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。
(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。
(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。
(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。
(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。
(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？
(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。
(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。
(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。
“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”
----------摘抄自《OOD 启思录》--Arthur J.Riel 著 鲍志云 译
(1)所有数据都应该隐藏在所在的类的内部。
(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。
(3)尽量减少类的协议中的消息。
(4)实现所有类都理解的最基本公有接口。
(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。
(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。
(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。
(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .
(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。
(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.
(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。
(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。
(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。
(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。
(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。
(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。
(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。
(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。
(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。
(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类
中。
(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。
(22)尽量减少类的协作者的数量。
一个类用到的其他类的数目应当尽量少。
(23)尽量减少类和协作者之间传递的消息的数量。
(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。
(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。
(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。
(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。
(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。
当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。
(29)让系统功能在窄而深的继承体系中垂直分布。
(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。
(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。
(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。
(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。
(34)类必须知道它包含什么，但是不能知道谁包含它。
(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。
(61)不要绕开公共接口去修改对象的状态。
