飞跃迷雾，把OO看清楚（二）
（二）不值得做的事情，更不值得做好——再探需求
有的人说，软件建模过程有一套科学的方法论，有自己的规律，是软件长期发展演进总结出来的。对此，我是赞同的。也有人对上面电梯例子列举了一些更加优化改进的业务流程，比如更科学的算法以至于让等待电梯的人获得更加公平的机会。对此，我也认为这可能是电梯未来的发展方向。但是，以上两者看似无关联的意见以及我们讨论的电梯例子都忽视了一个重要的因素——需求，更进一步说是客户欲望。
这里可能有个问题，难道电梯运行流程不是需求吗？如果将需求看成客户欲望，那么电梯流程就不是需求。我上面例举的电梯系统，其实没有引入一个软件系统的重要因素——客户。不同客户有着不同的需求，如果客户是电梯整套设备制造商，那么他的诉求可能是安全、稳定、长期运行、无人看守等等；如果客户是要开发一套如“电梯惊魂”之类的惊悚类游戏，而要模拟一个不太正常的电梯，那么客户的诉求可能是不确定、阴暗、复古、恐怖等等。这样，客户不同，我们就得出侧重点不同的电梯（也有可能连电梯都不是）。
光讨论方法论是不够的。比如，有人说，有一套杀死蟑螂万无一失的方法——将蟑螂固定在一块木板上，用另外一块木板敲打它。这样做，蟑螂肯定必死无疑，问题是没有人会花钱“引进”这套方法。因为这个方法把最难的部分——将蟑螂固定在木板上（可以把这个过程看成捕获需求）交给了客户。所以方法论可以解决我们“怎么做”的问题。但是，不能解决“做什么”的问题。先搞清出发的方向，再考虑怎么走。我同意软件建模是有一套科学的、有规律的方法，但是不同意有了这个共识就使得建模结果趋于一致。因为即便相同的客户和相同的方法论，建模者对需求不同的考量，也会产生不同的软件模型。
写到这里，我考虑回头再看看我的标题——飞跃迷雾，把OO看清楚。我看见过，有老前辈这样的言论：“软件工程看起来已经‘进化’成一门诡辩方法论的科学，它不去解决引起问题的根源，而是力图去安抚和使用花言巧语来哄骗参与其中的人们”。可能言过了，但是事实正在向这方面发展。现在很多人在软件工程领域就言必称“模式”、“框架”，还有层出不穷的方法论，仿佛越是晦涩难懂，越让人感觉有见解有深度。我并不是贬低那些模式、框架、方法论。有人将模式定义为一种表达一定的上下文、问题和解决方案之间某种特定关系的三部分规则。我则认为，这个“上下文”、“问题”、“解决方案”三要素也可以引申到框架、方法论中。而现在正是这许多抛开“上下文”只由“问题”和“解决方案”构造的软件工程领域，让人感觉浓雾重重，深陷其中不知所在。
在软件工程世界里，一名战士手拿OO（抽象化）这把利剑，毫无畏惧的向一头怪兽，一头总是在变化的怪兽——需求，刺去……