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