面向对象设计原则

㈠ 面向对象设计原则有哪些

SRP单一职来责原则
就一个类而言源，应该专注于做一件事和仅有一个引起它变化的原因。
OCP开放－－封闭原则
对于扩展开放，对于修改封闭。
LSP里氏替换原则
子（继承）类能在程序中代替父类（C#：基类，Java：超类）。
DIP 依赖倒置原则
抽象不依赖于细节，细节应该依赖抽象。（面向抽象编程，C#为面向接口编程）。
ISP接口隔离原则
接口属于用户类。（接口面用用户类，不用想着和自身层次、方法相关）
REP重用发布等价原则
重用的粒度就是发布的粒度。（？这个没有具体的认识）
CCP共同封闭原则
对于需求的响应，一个包中的所以类，有一个共同的响应（改变），而对于包外是不造成影响。
CRP 共同重用原则
包中的所有类共同重用，就是要重用就全部重用。
ADP 无环依赖原则
依赖关系不要存在环。
ADP 稳定依赖原则
朝着稳定的方向进行依赖。
SAP稳定抽象原则
包的抽象程度应该和稳定程序一致。

㈡ JAVA面向对象设计有哪些原则

一、单一职责原则（SRP）
就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。

二、开闭原则（OCP）

软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说：对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。

三、替换原则（LSP）

子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。

四、依赖倒置原则（DIP）

1、高层模块不应该依赖于低层模块。二者都应该依赖于抽象。2、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个\"硬伤\"。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。

五、接口分离原则（ISP）

采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

以上五个原则是面向对象中常常用到的原则。此外，除上述五原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化（一个类对应一个具体职责）等可供我们在进行面向对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有较低的设计复杂度。一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。

---------------------------------------------------------------------------------------------------------

“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”

----------摘抄自《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)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。

(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)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。
(61)不要绕开公共接口去修改对象的状态。

㈢ 面向对象原则

面向对象的原则，面向对象，应该有自己的做人的底线和原则信信。

㈣ java面向对象设计原则和设计模式详解

Java面向对象设计原则
1) Open-Close Principle（OCP），开-闭原则，讲的是设计要对扩展有好的支持，而对修改要严格限制。这是最重要也是最为抽象的原则，基本上我们所说的Reusable Software既是基于此原则而开发的。其他的原则也是对它的实现提供了路径。
2) Liskov Substituition Principle（LSP），里氏代换原则，很严格的原则，规则是“子类必须能够替换基类，否则不应当设计为其子类。”也就是说，子类只能去扩展基类，而不是隐藏或覆盖基类.
3) Dependence Inversion Principle（DIP），依赖倒换原则，“设计要依赖于抽象而不是具体化”。换句话说就是设计的时候我们要用抽象来思考，而不是一上来就开始划分我需要哪些哪些类，因为这些是具体。这样做有什么好处呢？人的思维本身实际上就是很抽象的，我们分析问题的时候不是一下子就考虑到细节，而是很抽象的将整个问题都构思出来，所以面向抽象设计是符合人的思维的。另外这个原则会很好的支持OCP，面向抽象的设计使我们能够不必太多依赖于实现，这样扩展就成为了可能，这个原则也是另一篇文章《Design by Contract》的基石。
4) Interface Segregation Principle（ISP），“将大的接口打散成多个小接口”，这样做的好处很明显，我不知道有没有必要再继续描述了，为了节省篇幅，实际上我对这些原则只是做了一个小总结，如果有需要更深入了解的话推荐看《Java与模式》，MS MVP的一本巨作！^_^
5) Composition/Aggregation Reuse Principle（CARP），设计者首先应当考虑复合/聚合，而不是继承（因为它很直观，第一印象就是“哦，这个就是OO啊”）。这个就是所谓的“Favor Composition over Inheritance”，在实践中复合/聚合会带来比继承更大的利益，所以要优先考虑。
6) Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法则或最少知识原则，这个原则首次在Demeter系统中得到正式运用，所以定义为迪米特法则。它讲的是“一个对象应当尽可能少的去了解其他对象”。也就是又一个关于如何松耦合（Loosely-Coupled）的法则。
设计模式：
1）适配器模式
http://eneasy.javaeye.com/blog/174838
2）桥接器模式
http://eneasy.javaeye.com/blog/174892
3）职责链模式
http://eneasy.javaeye.com/blog/174906
4）命令模式
http://eneasy.javaeye.com/blog/174896
5）装饰器模式
http://eneasy.javaeye.com/blog/174840
6）外观模式
http://eneasy.javaeye.com/blog/174890
7）工厂模式
http://eneasy.javaeye.com/blog/174831
8）享元模式
http://eneasy.javaeye.com/blog/174891
9）代理模式
http://eneasy.javaeye.com/blog/174887
10）单例模式
http://eneasy.javaeye.com/blog/174829
11）状态模式
http://eneasy.javaeye.com/blog/174897
12）策略模式
http://eneasy.javaeye.com/blog/174894
13）模板模式
http://eneasy.javaeye.com/blog/174893
14）访问者模式
http://eneasy.javaeye.com/blog/174914

㈤ 面向对象应该遵循什么原则

题目太宽泛了，你就跟考官随便扯点。。。

1.封装原则，简单的说就是不改给人看见的就不要让人看见，就好比冠生园生产月饼，里面的心都是封装在皮下面的，要不是被曝光你根本不知道它已经过期了。。。

2.努力降低类之间的耦合度，就像一个女人盘了个发髻，看着舒服，但盘起来那是相当的费劲，头皮上再来个虱子，手都不知道怎么伸进去挠痒。同样在类设计中，不要让各个类之间发生过多依赖关系，系统中的职责要分配给不同的对象去完成，对象之间不应该越俎代庖，只需做好本职就行了

3.好莱坞原则，它允许低层组件将自己挂钩到高层组件上以供使用。如果高层类依赖底层的方法，底层又调用高层的，这就形成了环形依赖，典型的依赖腐败啊！怎么治理，一句话，只需周官放火，不许百姓点灯。。。

4.开闭原则：对扩展开放，对修改关闭。尽量不要修改已经完成的模块来实现功能的扩展，不说啥了。。。

推荐楼主去看head first design pattern，或许能对楼主有所帮助

㈥ 面向对象设计的6个设计原则最早谁提出的

Booch最先描述了面向对象的软件开发方法的基础问题。

面向对象设计的六大基本原则:
1)开闭原则
2)里氏代换原则
3)依赖倒转原则
4)接口隔离原则
5)迪米特法则
6)合成/聚合复用原则

㈦ 面向对象的核心原则是什么

61条面向对象设计的经验原则
摘抄自《OOD 启思录》--Arthur J.Riel 著 鲍志云 译

“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”

“你不必严格遵守这些原则，违背它们也不会被处以宗教刑罚。但你应当把这些原则看成警铃，若违背了其中的一条，那么警铃就会响起。”

----------Arthur J.Riel

(1)所有数据都应该隐藏在所在的类的内部。p13

(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。p15

(3)尽量减少类的协议中的消息。p16

(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 p16

(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。p17

如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。

(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。p17

(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。 p18

(8)类应该只表示一个关键抽象。p19

包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .

(9)把相关的数据和行为集中放置。p19

设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。

(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。p19

朝着稳定的方向进行依赖.

(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。p23

(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。p30

(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。p30

规划一个接口而不是实现一个接口。

(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。p30

(15)对包含太多互不沟通的行为的类多加小心。p31

这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。

(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。p33

(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。p36

(18)从你的设计中去除不需要的类。p38

一般来说，我们会把这个类降级成一个属性。

(19)去除系统外的类。p39

系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。

(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。p40

(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。p43

(22)尽量减少类的协作者的数量。p52

一个类用到的其他类的数目应当尽量少。

(23)尽量减少类和协作者之间传递的消息的数量。p55

(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。p55

(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。p55

(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。p55

(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。p57

(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。p57

当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。

(29)让系统功能在窄而深的继承体系中垂直分布。p58

(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。p60

(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。p60

(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。p60

(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。p60

(34)类必须知道它包含什么，但是不能知道谁包含它。p61

(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。p61

(36)继承只应被用来为特化层次结构建模。p74

(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。p74

(38)基类中的所有数据都应当是私有的，不要使用保护数据。p75

类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。

(39)在理论上，继承层次体系应当深一点，越深越好。p77

(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。p77

(41)所有的抽象类都应当是基类。p81

(42)所有的基类都应当是抽象类。p82

(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。p85

(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。 p88

(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。 p89

(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。 p89

(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。p89

(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。 p96

(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。p97

(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。p99

(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。 p103

(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。p103

(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。p108

(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。p112

(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。p120

(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？p121

(57)如果你在一个面向对象设计中发现了多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。p122

(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。p135

(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。p140

(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。 p149

(61)不要绕开公共接口去修改对象的状态。p164

----------Arthur J.Riel

㈧ 面向对象设计中的要素与原则有哪些

面向抄对象三要素
封装(Encapsulation)
继承(Inheritance)
多态(Polymorphism)
面向对象五原则
单一职责原则(SRP)
开放-封闭原则(OCP)
Liskov替换原则(LSP)
依赖倒置原则(DIP)
接口隔离原则(ISP)

面向对象六视点
复用(Reusibility)
扩展(Extensibility)

㈨ 面向对象设计的原则是什么

SRP单一职责原则 就一个类而言，应该专注于做一件事和仅有一个引起它变化的原因。 回OCP开放－－封闭答原则 对于扩展开放，对于修改封闭。 LSP里氏替换原则 子（继承）类能在程序中代替父类（C#：基类，Java：超类）。 DIP 依赖倒置原则 抽象不依赖于细节，细节应该依赖抽象。（面向抽象编程，C#为面向接口编程）。 ISP接口隔离原则 接口属于用户类。（接口面用用户类，不用想着和自身层次、方法相关） REP重用发布等价原则 重用的粒度就是发布的粒度。（？这个没有具体的认识） CCP共同封闭原则 对于需求的响应，一个包中的所以类，有一个共同的响应（改变），而对于包外是不造成影响。 CRP 共同重用原则 包中的所有类共同重用，就是要重用就全部重用。 ADP 无环依赖原则 依赖关系不要存在环。 ADP 稳定依赖原则 朝着稳定的方向进行依赖。 SAP稳定抽象原则 包的抽象程度应该和稳定程序一致。

㈩ 面向对象五项基本原则

◆ SRP，单一职责原则，一个类应该有且只有一个改变的理由。

◆ OCP，开放封闭原则，你应该能够不用修改原有类就能扩展一个类的行为。

◆ LSP，Liskov替换原则，派生类要与其基类自相容。

◆ DIP，依赖倒置原则，依赖于抽象而不是实现。

◆ ISP，接口隔离原则，客户只要关注它们所需的接口