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