本文主要是介绍设计模式系列·王小二需求历险记(二)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
0x1 原文再续，书接上回
上回说到，C哥凭借自己多年的编码经验，欲传授王小二绝世武功。
让我们书接上回。
0x2 来源于生活中的实例
看着王小二求知若渴的眼神，C哥开始对小二循循善诱。
“小二啊，我们假设一个场景：假设你是一名讲师，对于上完你课程的人，你要确保接下来，每个人都知道他们下一节课去哪上。你如何去做呢？”
“嗯…我会在教室门口贴一张课表。课表上标明所有的课程以及课程对应的教室。让学生们自己根据课表去找就行了。”
“不错！小二很聪明嘛。但是如果把这个场景转换为程序实现，你起初可能就不会这样设计了”。
“为什么？”小二睁大眼睛问道。
“因为面对需求，你首先想到的是过程化的解决办法。比如在你设计发送消息的需求的时候，就是典型的过程化的思维模式。上面那个讲师的场景，你转换成程序可能会这么做：
- 获得课堂上每个人的名单;
- 对于名单上的每个人：
a.查找他的下一节课程;
b.查找他的下一节课程的地点;
c.告诉他去哪里上下一节课。
为了实现上面的过程，你可能需要：
1. 获得课堂上每个人名单的方法;
2. 获得每个人课表的方法;
3. 获得每个课程对应的教室的方法;
4. 告诉学生去相应教室上课的方法;
5. 一个控制程序为每个人做需要的步骤。”
王小二沉思了一会，若有所思的点点头：“嗯，确实会这么做”。
0x3 趁热打铁·责任的转移
“小二啊，上面我们说了两种解决办法。你觉得这两种解决办法哪种更好些呢？”C哥问道。
“当然是第一种了，现实生活中我可不会傻到自己挨个去查学生的课表，地点，然后挨个告诉学生，那多累啊。”
“是啊，肯定是第一种解决办法好。其实，你仔细想想，这两种解决方式，最大的不同点是哪里？”
“嗯…想不出来。”
“最大的不同点，是责任的转移。你看第一种解决办法，你只需要把课表张贴出来，学生自己去查询课程、教室就行了。完成这件事情，既有老师的责任，也有学生的责任。而第二种方法，从头到尾都需要老师去做，责任都在老师身上。”
“每个人的责任边界划分的很清楚，每个人都对自己的事情负责，各司其职。这也就是我们常讲的低耦合。这样的代码很好维护、扩展，当需求有所改变时，我们就能很好的去应对。你好好想想是不是…”
0x4 发送消息的重新设计
C哥提到，一种方式是面向过程，一种方式是面向对象。
两种方式最大的不同就是责任的转移。
王小二若有所悟，决定重新设计下发送消息的那个需求。
按照小二的想法，发送消息需要如下类(或实体)，才能实现责任的界定、转移。从而将程序解耦。
小二先把类图设计了出来。
设计完毕，顿时觉得思路清晰了好多。
用面向对象的方式去实现这个需求，如何实现呢？
- 开始控制程序;
- 对相应的vip用户做初始化;
- 告诉相应的vip用户，发送信息;
- 每个vip用户:
a.确定自己要发送什么类型的消息(短信、微信、email…)
b.发送消息
如此，就实现了解耦。真是能量满满。
0x5 再也不怕需求变了
根据上面的设计，小二又用相应的代码进行了实现。
“需求爱咋变咋变，这次不怕了，哈哈”，小二窃喜道。
比如，现在需求变化了。
产品经理说:”需要给年Vip用户发送短信、邮件。其他Vip用户不变”。
王小二想到：“哈哈哈哈哈，需求随便改，我终于不再需要改那一大坨代码了，我只需要改年Vip用户的类就可以了。”
如图，需要改一个地方，其他地方不会有任何影响。
看，解耦之后，就是这么的灵活、有魅力。
更多精彩，请关注公众号“聊聊代码”，让我们一起聊聊“左手代码右手诗”的事儿。
这篇关于设计模式系列·王小二需求历险记(二)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
