EE vs. CS

这是一篇很古老的文章，翻译得不好，大家将就着看。

固定链接：http://share.solrex.org/os/ee_vs_cs_cn.html

从前，在一个离这儿不远的国家，一个国王召来他的两个谋臣进行一项测试。国王给他们看了一个闪闪发光的金属盒，盒子上面有两个插槽，一个控制按钮和一个手柄，然后问道：“你们认为这是个什么东西？”

其中一个谋臣，电子工程师，抢先答道：“陛下，这是一个烤吐司机。”国王问他：“如果让你给它设计一个嵌入式计算机，你会怎么做？”这个工程师回答说：“利用一个4位的微控制器即可，我将写一个简单的程序读入亮度盘（译注：the darkness knob，不知道是什么东西），将其量化到从雪白到煤黑的 16 阶亮度水平上。这个程序将使用该亮度水平作为 16 个初始时间值表的索引，然后启动加热元件，用该亮度水平映射到的时间初始化计时器。在计时结束后，关掉加热元件，弹出烤好的吐司。如果您愿意的话，下星期我就能给您一个可以工作的原型。”

第二个谋臣，计算机科学家，立刻认识到了这种短视想法的危险。他说：“烤吐司机并不仅仅是用来把面包变成吐司的，它们同样会被用来加热冷冻华夫饼。在您面前所放置的其实是一个早餐厨具，当您的臣民变得越来越老练时，他们将需要它提供更多功能。他们会希望早餐厨具同样可以用来烤香肠、煎培根和炒鸡蛋，一个只能做吐司的烤吐司机将会很快被大众废弃。如果我们不未雨绸缪，在不远的几年后我们就不得不完全重新设计烤吐司机。”

“考虑到这一点，我们可以制定一个更好的解决方案。首先，创建一个早餐食品基类，特殊化这个基类到几个派生类：谷物、猪肉和禽肉。特殊化的过程可以重复进行下去，比如谷物可以派生出吐司、松饼、薄煎饼和华夫饼；猪肉可以派生出香肠、links和培根；禽肉可以派生出炒鸡蛋、煮鸡蛋、荷包蛋、煎鸡蛋和多种煎蛋卷类。”

“火腿奶酪煎蛋卷类尤其值得特别注意，它必须同时继承猪肉、奶制品和禽肉类的特点，除了使用多重继承，这个问题无法得到妥善解决。在运行时，该程序必须创建合适的对象，并发送消息到该对象：‘把自己弄熟。’当然，由于多态性，这条消息的语义取决于该对象的类型，所以它对于吐司对象和炒鸡蛋对象分别具有不同的含义。”

“回首目前我们的进程，可以看到，分析阶段揭露了一个基本的需求，那就是该厨具需要能做出任何种类的早餐。在设计阶段，我们发现了一些衍生的需求，特别是我们需要一个面向对象的、支持多重继承的语言。当然，没有哪个用户希望当煎培根时鸡蛋变凉了，所以并行处理能力也是必要的。”

“我们绝对不能忘记用户界面。用来控制食物的手柄缺乏通用性，亮度盘令人困惑。一个产品必须具有友好的图形界面，否则不会受到市场欢迎。当这个早餐厨具启动时，用户应该看到一个牛仔出现在屏幕上。用户点击它后，一条消息“正在启动 UNIX v.8.3”将显示在屏幕上。（当该产品推出时，Unix 8.3 应该已经发布了。）然后用户可以下拉菜单，点击他们想做的食品。”

“当在设计阶段做出首先规划软件的聪明决策之后，在实施阶段剩下的只是选择一个合适的硬件平台了。一个使用 Intel 80386 CPU，拥有 8 兆内存、30 兆硬盘和 VGA 显示器的机器应该足够了[1]。如果你选择了一个多任务、面向对象、支持多重继承且内建图形用户界面库的编程语言，写这样一个程序是件轻易而举的事情。想想如果我们傻乎乎地允许一个硬件优先、将我们锁定在一个 4 位微控制器上的愚蠢设计将会给我们带来多少困难！”

国王听完他这番话，作出了将这个计算机科学家斩首的英明决定。人们从此过上了幸福快乐的生活。

[1] 在这篇文章出现的当时，这应该算是挺先进的配置了。