【设计模式】之六大原则（一）

 

 

                         【设计模式】之六大原则（一）

  

目录

一、单一职责

   1、问题由来

   2、解决方案

   3、定义

   4、生活化

   5、单一职责优点

二、开放封闭原则

   1、定义

   2、问题由来

   3、解决方案

三、依赖倒转原则

   1、问题由来

   2、定义

   

  设计模式的学习贯彻着整个学习、编程和架构，最开接触的是从大话设计模式接触设

计模式之六原则，最近通过和师哥师姐的设计模式交流会，最近又借软考之际在此复习

小结一下设计模式之六大原则；他们分别是单一职责、开放封闭原则、依赖倒转原则、

里氏代换原则、迪米特原则和合成/聚合原则下面我们一起来看看具体这些原则是什么

呢？

               

                     

 

 

一、单一职责：（Single Responsibility Principle）

 

 1、问题由来：生活中犹如摄像功能的手机和摄像机，手机会有很多的功能，但是摄像

机就是单纯的一个功能，在摄像方面，摄像机就是做精了，做到功能单一！

   

   又如程序中类A 负责两个不同的职责：B1，B2，当由于职责B1 需求方式改变而需修

改类 A 是，有时可能导致真诚|职责B2功能发生故障。

 

 

   2、解决方案：通过单一职责原则来解决，分别建立两个类 B1，B2，使A1完成B1功

能，A2完成B2功能，这样，当修改类A1时，不会使职责B2发生故障风险；同理改A2

时，不会使职责B2 发生故障风险。

 

 3、定义：简单的理解就是一个类中，应该仅有只有一个引起它变化的原因。【ASD】

一个类，或者一个接口，最好只做一件事情，当发生变化时，他只能受到单一的影响；

因为职责过多，可能引起变化的原因将会很多，这样导致职责和功能上的依赖，将严重影响其内聚性和耦合度，混乱由此而生。

 

 

4、生活化：

  

   单一职责的原则在现实生活中早就实践于现代公司体制与工业生产上，如公司的各个

部门职责分明相互独立，生产流水线的某一环节只需关注上螺丝，而另一环节只做零件

组装等等；这一原则使庞大的系统组合起来还能各司其职，井井有条，即使某个部门、

某个环节出了问题或需要改动，你只需去动那个要变动的地方即可，从而避免因职责功

能不明而导致不必要的的混乱。

   同样，程序代码的设计也是如此，功能和职责单一化也是衡量代码优良的一个标准；

交杂不清的职责和功能将使得代码看起来特别别混乱、别扭且一发而动全身，更严重的

是在日后的维护中你得花更多的时间去理清他的逻辑，并且这地方的变动几乎是必然引

起让人头痛的BUG，你将花费更多的精力，承担更多的风险！

    

  在代码工程的实施中，遵循单一职责原则将会带来诸多好处：类的复杂性将降低，简

单明细的代码将使可读性将大大提高，自然而然可维护性亦将同步提高，可维护性提高

将预示着因变更引起的风险会大大降低，最重要的前边的好处将会是你工作轻松愉悦、

思路清晰、远离脑爆头大……专注即高效，单一既轻松，人事皆如此。

 

      5、单一职责优点：

（1）可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单

的多；

（2）提高类的可读性，提高系统的可维护性；

（3）变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功

能时，可以显著降低对其他功能的影响。

    这里要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化

的程序设计，都需要遵循这一重要原则。

 

  

二、开放封闭原则：（OpenClose Principle）

1、定义：对于扩展是开放的（Open），对修改是封闭。

 

2、问题由来：在软件的生命周期中，因为变化、升级和维护等原因需要对软件原有代

码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重

构，并且需要原有代码经过重新测试。

 

3、解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是

通过修改已有的代码来实现变化。

   比如，内存不够只要插槽足够就可以添加，硬盘不够就可以用移动硬盘等等。

   开闭开闭，开放封闭。开放的是拓展，封闭的是修改，即降低耦合，封装变化的集中

展现。开放扩展，则意味着当有新的或变化的需求时，可以通过对现有代码的拓展来实

现，而不需要该变原有程序的结构与内容；封闭修改，指的是程序设计一旦完成，其预

定功能即按照既定独立工作，在不可对其做修改操作（太绝对了、太完美了！）开闭原

则的核心思想就是抽象编程，而不是对具体，因为抽象是相对稳定的，再说了我们还有

接口

 

 

 三、依赖倒转原则：（Dependence Inversion Principle）

   1、问题由来：会修电脑不会修收音机？

    2、定义：重要的三层含义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；

抽象不应该依赖细节；细节应该依赖抽象。其核心思想是：依赖于抽象。换句话说就是

要针对接口编程，不要对实现编程。

 

   关于“倒置”这个词。准确的讲，这是因为传统的软件开发方法，如结构化的分析和

设计，倾向于创建高层模块依赖于低层模块、抽象依赖于具体的软件结构。在实际上，

这些方法的目标之一就是去定义描述上层模块如何调用低层模块的子程序层次结构。所

以，相对于传统的过程化的方法通常所产生的那种依赖结构，一个设计良好的面向对象

的程序中的依赖结构就是“被倒置”的。

 

    其中还有里氏代换原则、迪米特原则以及合成/聚合复用原则又是什么，它们有什么特

性呢，看一博文。