【DM】设计模式再回顾---职责单一+开放-封闭

写在前面的

• 在之前的文章中，很多次都提到了开放-封闭以及高内聚、低耦合的程序设计原则。今天我们就继续来总结一下职责单一+开放-封闭。我之所以把这两个合到一起来总结就是因为当你的程序在一定的程度上符合了职责单一原则，其实对于开放-封闭原则也就达标了，为什么这么说？看完我的这篇文章也许你就对这种思想有一个新的认识。

职责单一

概念

• 在书上给出的定义中说道：职责单一原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。

我的理解

• 非常好理解的一句话，但是我觉得这句话就像“好好学习，天天向上”一样，好说不好做。为什么？因为在实际的编程过程中很难达到完全符合这种思想的标准。举个栗子：比如我们日常编写的程序基本上都是按照功能来划分模块，即某一个或者几个模块去实现某种功能。那么问题就来了，首先，我们先来考虑第一种情况—某一个模块实现一种特定的功能。在实际的编码中，有时会碰到这样一种情况，实现某一个特定功能的类由于这个功能使用率非常高，所以被其他的类模块给套用了，并且在这个类模块的基础上演变出来了其他的功能，虽说我们在“宏观”上也实现了职责单一，但是对于后期的运维阶段无疑是一个严峻的挑战（再加上一些程序员写备注的习惯不是很好，结果嘛…大家都懂…猜呗）,也就是在某种意义上破坏了开放-封闭原则。

• 然后，我们再来考虑第二种情况—多个模块去实现某种特定功能。先声明一下，这里的“多模块”实现“单一功能”并没有违背“职责单一”原则，因为也许这种“特定的功能”需要多个“职责单一的模块”同时实现。但是这样的庞大的模块群必然会会导致一种现象发生，那就是模块与模块之间的“耦合度”会直线上升，后期维护工作同样会面临巨大挑战。

• 那么，这个东西到底怎么用？我们就得分析一下“开放-封闭”了。

开放-封闭

概念

• 开放-封闭原则：对于软件实体（类、模块、函数等等），应该可以扩展，但是不可以修改。

我的理解

• 对于这个原则来讲，它是我们在设计模式中的一条黄金原则，当然，做到也非常困难，所以我们只能在实战中尽力去做到。主要就是为了达到代码的“高效，可复用”，减轻运维压力。结合我们之前留的一个小问题，我们具体来对比总结一下。

对比总结

• 首先，我们必须要承认，书上的金科玉律都是正确的，然后我们才能在这样的基础上阐述我们自己的观点。

• 其次，我们来剖析一下设计模式中的原则。正是因为我们有了职责单一+开放-封闭，才能使我们的程序的框架有一个非常清晰的轮廓，然后我才能在这样一个划定的范围内进行非常高效的编程工作。但对于这个框架要按照多么具体的功能划分，那就需要我们按照需求的粒度去做出我们自己的判断了。这并不是把“锅”甩给“经验”，而是因为我们可以在总结需求的过程中非常清楚的提炼出来，并且这个过程与“经验”的关系不大。

• 最后，在我们按照“需求”严格的推算出粒度之后，在这个大框架下，我们的“职责单一”也好，“开放-封闭”也好，“高内聚、低耦合”也好，就已经全部的符合我们的程序设计要求了。

写在后面的

• 自己不太擅长写这种纯理论的文章，也不知道我的思路能不能通过文字准确的表达出来，但是人嘛，成长还是需要锻炼的，希望自己总结的文章能为后来者乘凉之用。也希望刚刚接触设计模式的小鸟们不要死磕原则，只要合理、可行、高效，那么这个模式就是一个非常棒的设计模式架构。

TO BE CONTINUE……