有同学在我的视频下留言：
其实认真看我的视频或书就明白，这和我说的不是一回事。
这个留言有点新意，和以往的留言如“人能说话，嘴就是人的说话模块，没错啊！”是不一样的，所以我特地来说一下这个留言，它体现了开发人员容易出现的一些问题：
（1）不知不觉切换研究对象
我们先来看“以人为例，心脏的功能是泵血”。
我的视频或书里的图是这样的：
“以人为例”，这时候研究对象是“人”，这时候说“功能”应该说“人”的功能，例如“扛煤气罐”，“功能模块”指的是“扛煤气罐模块”、“扛煤气罐子系统”。
外面的老板、老婆、老爸老妈、要的就是这些“功能”，人的构造是心肝脾肺肾还是电路板，其实无所谓，甚至经过“机械飞升”的身体更受欢迎！
研究“人”的时候，“心脏”和“泵血”只是人的一种可选的设计方案，不是需求。而“功能”说的是需求。
这位同学在这里，不知不觉切换了研究对象。
“不知不觉切换研究对象”可谓开发团队的一个大毒瘤。有的人可能出于无知，可能出于维护面子，可能出于逃避责任，经常有意无意祭出这件法宝。
你和他谈组织流程，他和你谈某个类的代码，你和他谈某个类的代码，他又和你谈组织流程。
开头的图片说到心脏，我们把这个套路继续往小里用，也可以说：
以人为例，神经细胞的功能是传递信号，神经细胞是个模块，所以：神经细胞是传递信号模块，没毛病吧！
以人为例，原子的功能……
（2）把行为和类一一对应
假设我们不研究人这么大的范围，改为研究心脏。我们要生产或培养棒棒的心脏，“卖”给需要的人或动物。
既然已经是研究心脏了，这时候，“心脏”就是我们研究的目标系统。
“泵血”是心脏的功能，这个没问题，但是，心脏还有其他功能：回收废物、调节内分泌。
我们所研究的系统的名字却不叫“泵血系统”、“回收废物系统”、“调节内分泌系统”或者“泵血+回收废物+调节内分泌系统”，它就叫“心脏”。
同理，心脏的使用者要的就是心脏的功能和性能。心脏是由肉还是电路板构成，这也是可选的设计方案。
注意，此时心脏是我们所研究的系统，不是“模块”。
当心脏被“卖”出去，安装在人体内，这时心脏才会成为人的一个模块。
所以，“心脏的功能是泵血，心脏是个模块”这样顺下来的说法是不正确的。
同样，这个模块不叫“泵血模块”、“回收废物模块”、“调节内分泌模块”或者“泵血+回收废物+调节内分泌模块”，它就叫“心脏”。
我们可以再扩展开。假设心脏被安在某个公司员工（例如女秘书）身上，此时，这个女秘书也成为公司的一个“模块”，但是这个模块名字不叫“为老板做A+为老板做B+为老板做C模块”，她就叫“秘书”。
把行为和类一一对应，这样的思想有什么问题呢？
会导致得到的类是“泵血er”、“回收废物er”、“调节内分泌er”，得不到“心脏”这样一个类。
参见：
《软件方法》第8章>>
可能有的同学会想，这个不挺好吗，这不就是“微服务”吗？
是哦，好棒，什么也不用思考就解决了复杂问题，天上真的掉免费的午餐了吗？
参见：
《软件方法》第1章>>
**********
9389
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
