一．面向对象设计的七大原则是什么？

1.开放封闭原则

2.里氏转换原则

3.依赖倒转原则

4.组合/聚合原则

5.接口隔离原则

6.“迪米特”法则

7.单一职责原则

二．七大原则是什么含义？

序号	面向对象设计七大原则	偶的理解
1	开放封闭原则	面向扩展开放，面向修改关闭
2	里氏转换原则	超类存在的地方，子类是可以替换的
3	依赖倒转原则	实现尽量依赖抽象，不依赖具体实现
4	组合/聚合原则	要尽量使用合成/聚合达到复用，而不是继承关系达到复用的目的。
5	接口隔离原则	应当为客户端提供尽可能小的单独的接口，而不是提供大的总的接口
6	“迪米特”法则	又叫最少知识原则，一个软件实体应当尽可能少的与其他实体发生相互作用
7	单一职责原则	每一个类应该专注于做一件事情

 

三．解读七大原则：

1.开放封闭原则

偶的理解

偶是做底层的设计与编码，譬如：车载导航系统的引擎的。该引擎系统包括地图数据格式的解析，图层添加、修改、删除等；地图符号的编辑、显示与润色，基于两个地点之间的最短时间/最短距离的路径规划等等功能。

 

做车载导航系统的应用层的同事，不能修改偶核心层代码，也就是说您不能修改偶的接口，但是您可以针对偶的接口做一些扩展。也就是：对接口的修改是封闭，但是对接口的扩展是开放。

为什么这样？

1.同事修改偶的核心层代码不合适，毕竟这些偶是专门整天研究这个的，偶专业呀；

2.同事为了自己的一己私利，修改了接口（如添加参数，修改了参数数据类型或者去掉某个参数），但是基于偶的核心车载导航引擎的，不只同事一个人用，好多同事与第三方公司都编译不过，一堆会找上门来，骂你个狗血喷头；

3.但是同事，将偶的引擎接口扩展了，自己用，影响不到其他人，多好的一件事情；

2.里氏转换原则

任何基类可以出现的地方，子类一定可以出现。即超类存在的地方，子类是可以替换的。替换后行为不变，结果会变化。调用子类行为。

子类和父类必须有相同行为才能完全地实现替换。

实现开闭原则的关键是抽象化，而里氏代换原则中的基类和子类的继承关系正是抽象化的具体体现，所以里氏代换原则是对实现抽象化的具体步骤的规范。违反里氏代换原则

偶的理解

想通过基类的指针，调用虚拟函数，搞多态，让一个函数，针对不同的派生类指针，会有不同的表现行为。派生类的虚拟函数，不能搞特殊。派生类的指针不能赋值给基类，哪就胡扯。

 

里氏代换原则是要求我们在使用继承时，必须满足一定的条件。不能为了复用，一味去继承。

3.依赖倒转原则

抽象不应该依赖细节。细节应该依赖抽象。

偶的理解

设计接口的时候，不应该说俺设计的这一个接口，就是给这个某一个具体实现功能而设计。

哪就不叫面向对象设计了，抽象了也啥意思。因为你只为某一个具体功能而设计。

 

但是具体编码实现某一个功能，还是要依赖于某一具体的接口的。

 

注意这是面向对象设计，设计什么呢？设计接口。接口是一个一对多的关系。一对多啥意思，就是一个接口，有多种实现。

 

哦！明白了。多态，讲的就是这个意思，一个接口，多种行为方式。挂上钩了。O(∩_∩)O~。

类似：活着与吃饭的关系

活着不是为了吃饭，但是吃饭为了活着。

4.组合/聚合原则

偶的理解

《设计模式》里23个模式，就是整篇整篇地讲如何类与类之间的组合/聚合。

 

如果为了复用，便使用继承的方式将两个不相干的类联系在一起，违反里氏代换原则，哪是生搬硬套，忽略了继承了缺点。

 

继承的缺点有：

 

1、继承复用破坏数据封装性，将基类的实现细节全部暴露给了派生类，基类的内部细节常常对派生类是透明的，白箱复用。

虽然简单，但不安全，不能在程序的运行过程中随便改变。

 

2、基类的实现发生了改变，派生类的实现也不得不改变。

 

3、从基类继承而来的派生类是静态的，不可能在运行时间内发生改变，因此没有足够的灵活性。

5.接口隔离原则

应当为客户端提供尽可能小的单独接口，而不要提供大的总接口。暴露行为让后面的实现类知道的越少越好。

偶的理解

人家需要什么，你给人家提供什么。

否则如果接口给人家提供多了，暴露多了，自己的麻烦不少。人家会问：

1.这个接口是干什么的，怎么用啊；

2.这个接口与另外一个接口有什么区别啊？又有什么联系啊？什么情况下用这个接口，什么情况下用另外一个接口；

 

总之，问得你烦死了，烦透了。最后，没办法，只好弄一个版本，就是提供客户需要的接口，告诉他如何使用，一了百了。清闲自在多了。

 

真是你好！我好！大家好！

 

一旦某个漂亮的女孩子穿衣服，要是暴露多了，又露胸，又露屁股，被人家一阵狂扁，“看哪个不要脸的狐狸精”，“伤风败俗，缺家教”，“看又一个暴露狂”。搞的人家MM都要奔溃，跳黄河自杀。偶算明白了。技术原理来源于生活。道理都是相通的。O(∩_∩)O~

6.“迪米特”法则

又叫最少知识原则，一个对象对另一个对象知道的越少越好，即一个软件实体应当尽可能少的与其他实体发生相互作用。

 

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一方法的话，可以通过第三者转发这个调用。

偶的理解

一个类包装好自己的private状态和方法，不需要让别的类知道字段或者行为，就不要公开哟！

 

强调类之间的松耦合。

 

类与类之间的耦合性越低，一旦一个处于弱耦合的类的代码被修改了，不会对有关系的类造成波及与影响。这样，这个类的复用性大大增强，提高了开发效率，降低了出错的可能性。

 

哥最怕的是修改了某一个不起眼的类一点代码，跟她发生关系的类太多。牵一发而动全身。会发生多米诺效应。咱可惹不起。谁知道，会出现什么后果！汗颜！

7.单一职责原则

每一个类应该专注于做一件事情。

偶的理解

这个讲的就是商业领域里面的定位概念。想打官司，找律师；想看病，找医生；想学习，找老师。

 

一个类一个具体作用，如微软的VC MFC里的CBrush、CPen、CFont等就是这个意思，想搞字体用CFont，想用画笔用CPen，想用刷子，用CBrush。各司其责，一目了然。