亲亲宝宝

我们将从需求搜集入手，从分析到设计，然后完成设计的 Java 实现。到结束时，您将经历开发 OO 程序的全过程，真正地从开始到结束。我将花很大的篇幅讨论基本理论，但主要重点仍将集中在如何应用该理论的实际示例上。
OO 并非关于结构

首先，就其核心而言，面向对象与派生、类层次结构、UML、Java技术等毫无关系。这些是 OO设计人员用来构成分析、设计和实现的工具，但它们并不是使程序面向对象的主要部分。当然，随着过程的展开，我将使用面向对象的所有这些结构性部件，但如果您将实现结构与面向对象等同起来，那么前几篇专栏文章可能特别难以理解。面向对象的关键概念是 建模，所以在动手之前，必须决定建立什么模型。Adele Goldberg（在 Succeeding with Objects中，请参阅 参考资料）叙述了一位犹太教教士在新年依始的宗教集会上讲述的故事：

一位教登上一列火车，由于他经常乘坐这辆车，因此列车长认识他。教士伸手到口袋中掏车票。但没有找到，他开始翻他的行李。列车长阻止了他：“教士，我知道您肯定有车票。现在别急着找。等找到后再向我出示。”但教士仍在找那张车票。当列车长再次见到他时，教士说：“你不明白。我知道你相信我有车票，但– 我要去哪里呢？

有太多项目失败就是因为它们没有明确的目标就开始了。OO过程试图通过首先解决这个问题来应付这种困境；需要几篇专栏文章才能足以细致地做到那一步，以便继续进行分析和设计阶段。即，在可以分析之前，要有东西 可以分析。

随意定制

下一步，描述的过程是我个人使用的。我并不打算使这些文章成为权威。我的工作方法类似于Booch、Rumbaugh 和 Jacobsen 的 RUP（Rational UnifiedProcess，请参阅 参考资料），但我并非有意为之。事情就是那样解决的。我的工作方法还类似于Kent Beck 的所谓 Extreme Programming（XP，请参阅 参考资料），但这只是一种巧合。我希望您能够根据自己的需要定制我所用的过程，以使之更可工作。考虑到文学作品十分缺乏任何过程的实践讨论，因此看起来对任何过程的实践讨论（甚至个人过程的讨论）都将十分有益。请不要费时考虑我是“对”还是错，只要记住我所做的只适用我个人，并且为使之更好地为您工作而变更我所做的方式完全没有错。

有关 OO 设计还要指出一点。有人曾告诉我说，他无法进行 OO设计，因为他支付不起：Rose 每客户要 2500 美元，而且显然，没有 Rose就无法设计。这里所讲的 “Rose” 是 Rational Software 所售的一种 OOCASE（计算机辅助软件工程）工具。（我可能会在以后的专栏中详述OO-CASE）。撇开 Rose既不是最划算、也不是功能最强大，更不是现有工具中最易使用的事实不说，我常常只用铅笔和纸、而不用任何高科技工具就能有效工作- 根本不用计算机。

正如我们要在即将出现的专栏中所见，OO过程实际上是一种语意分析形式。它与正式的语言学、而不是传统的过程设计技术有共同之处。我发现，计算机常常阻碍这种分析。您在工具上花的时间比实际完成工作所需的时间还要多。更糟的是，很多这些工具（包括Rose）都有令人讨厌而又苛刻的许可证管理器，它使您无法在没有通过网络与许可证管理器连接的便携式电脑上运行这些工具。当我使用计算机时，我通常使用一个绘图程序(Visio)，而不是 CASE 工具。（这并不是说，我认为 Visio是用于该目的的极好工具。只不过我恰巧有一份而已。我使用自己的模板 -请参阅 参考资料– 而不是内置 UML支持。）

我要说明的观点是设计与工具无关。设计是使您明确对复杂主题的自主想法，它是一种确保在开始编码之前尽可能全面考虑问题的方法，并且是与其它程序员就编码进行交流的方法。

由于在这里交流是真正的核心部分，任何对交流没有帮助的工具实际上都毫无价值。如果您单独坐在办公室内，面对基于计算机的CASE 工具，那么您就不是在交流。

选择 CASE工具无关紧要。我一般不使用任何工具，即使它们对较大的项目会有所帮助。其缺点是它们都会生成极差的代码，所以我不使用这些工具的代码生成或“往返工程”特性。无论如何，往返工程的观念–创建设计，生成代码，修改代码，然后将其逆向工程到“设计”，这是一种根本性错误的观念。设计本身应该是单向过程。先设计，然后根据设计实现。修改设计，然后实现修改过的设计。大多数这些工具无论如何创建出的设计都是不正确的，因为它们不能够仅仅通过查看代码就能逆向工程程序的动态行为。

对于我们的目的，相当好的绘图程序和字处理器就已足够。

设计环境和工具

设计始终是一种团体行为。最起码，需要程序员、测试人员、用户（或者完全了解问题领域的人）、写作很棒的人以及UI设计人员。您最好有书记方面的人员：能够记录和纂写，以及将手写的草图输入到绘图程序等等。您也可以不需要这些，但设计进度会减慢，因为小组成员不能够集中精力做他们的本职工作。

所有成员必须一起才能有效地工作，而且他们应该始终在一起。设计是专职活动，如果希望按时间表完成，就应该不要被其他事情打扰。（虚拟合作，可能的话使用白板软件或类似的。如果需要有效地沟通，要有视频和音频输入，才能使您看到和听到其他人员。）

可以有的最好设计工具之一是一间专为该用途设计的房间。我的理想工作间是一间令我心情愉快的房间。它有许多窗户和光线。墙上有可以挂白板的木板。（您可以买 4×8 大小，类似于 Home Depot用的三聚氰胺片，如果您愿意可以将它们安在墙上。）不要会议室 –扔掉会议桌和令人不舒适的椅子（我想，这样使会议尽可能短），换上一只舒适的沙发和几只扶椅。您需要装满食物的冰箱和需要时可以移动的小桌子。使用的主要设计工具是：白板笔和板擦，还有可以连到联网机器的LCD投影仪，所有这些可以使小组成员共同书写文档。用高分辨率照相机将图像从白板传送到计算机。最理想的是，将设计室和如Beck 在其 XP 一书中所述风格的工作室组合起来 -增加几个工作站群集和一些人们独处所需的私人空间。

通常，办公室里没有这样的空间，因此您可能得自己设计。取出螺丝刀，拆开小房间，组合成一个大房间。如果设备人员不喜欢这样，那么就强硬一些。对公司的成功更为重要的是：生产高质量软件，或支持“正确”办公室应该是什么样子的陈旧观念。

回页首

设计和体系结构

Microsoft 所犯的更可恶罪行之一是将动词 “to architect”引入到英语。设计师 设计房屋，但他们不“建筑”。我提出这个词语误用的原因在于，这种语言的滥用人为地暗示：房屋设计师和计算机程序设计师从事完全不同的活动。我坚信，无论设计房屋还是设计软件，设计就是设计。例如，ChristopherAlexander — 房屋设计师 — 设想了设计模式的概念（请参阅 参考资料中的 A Pattern Language: Towns,Buildings, Construction），而设计模式是当代软件设计的基础。

如果您对一个承包商说：“希望您为我建造一所房屋，它的造价有多少，您是否能完成？”。那他一定以为您疯了。然而，程序员肯定总在回答同样空泛的问题，而人们也在问：为什么软件很少按时并在预算内交付。此外，没有承包商愿意在没有某种计划那样复杂的情况下开工。然而，承包商自己设计的计划通常不会产生如设计师设计的那样好的房屋。承包商的设计很自然地会简化建造和降低成本，这不一定是您要居住的房屋的最佳选择。类似地，程序员通常不是最好的程序设计人员，因为他们的侧重点与最终用户不同。这并不是说，一名优秀的设计师不知道如何建造他所设计的房屋，-我确信最好的软件设计师也是最好的程序员 -而是说，设计和建造是两种不同的活动，不必由同一人来承担。

设计房屋的第一步是与客户协商，并构想如何使用该房屋。设计师感兴趣的是客户的美学，当然，他们还会问很多其它问题。有何爱好？（需要为这些爱好专门准备空间吗？）有宠物吗？要在厨房中准备喂猫的位置吗？）有孩子吗？（他们需要玩耍房间吗？）要几个玩耍房间？（玩耍房间要多大？）所有这些都影响房屋的设计。如果设计师对将在房间中发生的活动不熟悉，他们还必须学习这种活动，以达到令人满意的设计。比如，如果孩子养宠物鱼，那么，设计师还要学习池塘技术-不必达到宠物鱼的水准（用设计行话说，“领域专家”），但至少要达到具有相当知识的普通人水平。请注意，重点是将如何使用房屋。建造考虑，虽然总在设计师的考虑之内并影响设计，但不是主要的。

下一步是勾画大量房屋、房间、地面等。这时会有很多更改 –改变房间位置和外形、添加和除去固定设备和墙壁。只有当草图正确反映出客户需求时才可以说定制出一组“最终”计划，但即使这些计划也并非真正最终的计划。他们被提交给承包商和工程师，所有这些人都会请求更改，所有这些更改（如果可见，或至少影响成本或进度）都要由客户同意。只有在这时才开始建造。

计划中的细节级别也有关系。大多数设计工作在开始建造房屋时才开始进行。设计师指出墙壁伸展方向，但由承包商构想细节–壁骨放置、门窗的加框等。设计师指出电器开关的位置，而电工则构想如何布线和电气出口的位置。计划指出排水沟和排水管固定装置，而管道工则构想如何布置管道和连接到总水管和下水道。这不是说，不设计这些建筑部分，而是说，这部分设计由专门人员建造完成。设计工作常常是非正式的 -随工作进度现场进行。而且，大部分设计产物，如上面有绘图的纸片或墙壁内壁骨的草图，都被丢弃，因为在建好之后，它们不再有用。当技术人员需要做的事影响其他技术人员或整体建筑设计时，还要重新由设计师修改主计划（在征询客户同意之后）。

如果有简单和复杂的方法都可以解决同一问题，只要不影响结构的整体性和美感，则总是选用简单的方法。但是，有时只有复杂方法可以解决问题。值得注意的是，在建造开始之前所需的细节程度也决定了结构的复杂度。可以在一张餐巾纸上设计一间狗舍。而一间房屋则需要更多细节。事实上，一幢摩天大楼里的每一根管道和电缆管都要设计（尽管有时不设计墙的位置！）。

结束语

以上所述过程基本是与我用来创建软件相同的过程，它也是本专栏将逐一演示的过程。从下个月开始，我将讲解大量细节，以便可以将细节放在相关环境中讨论。实际上，很多这些操作都并行发生，我们将在今后几个月中看到。

1. 了解问题领域。
2. 与用户交流，并确定他们的需求和目标。
3. 开发问题说明书。
4. 设计用户界面。
5. 开发用例。
6. 拟出草案静态模型。
7. 在细化静态模型时开发动态模型。
8. 实现。

在逐一进行这些步骤时，我试图描述所发生的整个过程，包括所犯错误和如何修复错误。结束之后，您将对这种设计过程有完整（和现实）的认识。