1.9   分析和设计

面向对象范式是一种新的、不同的编程(www.cppentry.com)思考方式，许多人一开始在学习如何处理一个OOP项目时都会感到非常困难。但是了解到任何事物都被认为是对象，并且学会用面向对象的风格去进一步思考之后，我们就可以开始利用OOP所提供的所有优点创造出“好的”设计。

方法（method）［通常称为方法论（methodology）］是一系列的过程和探索，用以降低程序设计问题的复杂性。自从面向对象程序设计出现，已有许多OOP方法被提出来。本节将让读者感受使用一种方法时应完成什么任务？

尤其在OOP中，方法论是一个充满实验的领域，因此在我们考虑采用一个方法之前，理解它试图要解决什么问题是重要的。这在C++(www.cppentry.com)中尤其正确，这种编程(www.cppentry.com)语言在表达一个程序时试图减少复杂性（同C相比）。这在实际上可能减缓对更复杂方法论的需求。相反，简单的方法可以满足在C++(www.cppentry.com)中处理更大类的问题，在过程型语言中用简单方法处理的问题相比起来则小很多。

认识到术语“方法论”通常太大且承诺太多也是很重要的。设计和编写一个程序时，我们所做的一切就是一个方法。它可能是我们自创的方法，我们可能没有意识到正在创造一种方法，但它确实是我们创造时经历的一个过程。如果它是一个有效的过程，只需要略加调整以和C++(www.cppentry.com)配合。如果我们对自己的效率和程序生产方式不满意，就可以考虑采纳一个正式的方法或在许多正式方法中选择某些部分。

经历开发过程时，最重要的问题是：不要迷路。这很容易做到。大部分分析和设计方法都是为了解决最大的一些问题。记住，大多数项目并不适合这一点，因此我们通常可以用一个相对小的子集成功地进行分析和设计。但是采用某种过程，不论它怎么有局限，总比一上来就直接编码好得多。

在开发过程中很容易受阻，陷入“分析瘫痪状态”，这种状态中往往由于没有弄清当前阶段的所有小细节而感到不能继续了。记住，不论做了多少分析，总有系统的一些问题直到设计时才暴露出来，并且更多的问题是到编程(www.cppentry.com)或直到程序完成运行时才出现。因此，迅速进行分析和设计并对提出的系统执行测试是相当重要的。

这个问题值得强调。因为我们在过程型语言上的历史经验，一个项目组希望在进入设计和实现之前认真处理和理解每个细节，这是值得赞扬的。的确，在构造DBMS时，需要彻底理解用户的需要。但是DBMS属于能很好表述和充分理解的一类问题。在许多这种程序中，数据库结构就主要是问题之所在。本章讨论的编程(www.cppentry.com)问题属于所谓“不定（wild card）”（本人的术语）类型，这种问题的解决方法不是将众所周知的解决方案简单地重组，而是包含一个或多个“不定要素”—先前没有较了解的解决方案的要素，为此，需要研究。由于在分析阶段没有充分的信息去解决这类问题，因此在设计和执行之前试图彻底地分析“不定型”问题会造成分析瘫痪。解决“不定型”问题需要在整个循环中反复，且需要冒风险（这是很有意义的，由于是在试图完成一些新颖的且潜在回报很高的事情）。看起来似乎有风险是由于“匆忙”进入初步实现而引起的，但这样反而能降低风险，因为我们正在较早地确定一个特定的方法对这个问题是不是可行的。产品开发也是一种风险管理。

经常有人提到“建立一个然后丢掉”。在OOP中，我们仍可以将一部分丢掉，然而由于代码被封装成类，在第一次迭代中我们将必然生成一些有用的类设计，并且产生一些不必抛弃的关于系统设计的有价值的思想。因此，在问题的第一次快速遍历中不仅要为下一遍分析、设计及实现产生关键的信息，而且为下一遍建立代码基础。

也就是说，如果我们正在考虑的是一个包含丰富细节而且需要许多步骤和文档的方法学，将很难判断什么时候停止。应当牢记我们正在努力寻找的是什么：

(1) 有哪些对象？（如何将项目分成多个组成部分？）

(2) 它们的接口是什么？（需要向每个对象发送什么信息？）

只要我们知道了对象和接口，就可以编写程序了。由于各种原因我们可能需要比这些更多的描述和文档，但是我们需要的信息不能比这些更少。

整个过程可以分5个阶段完成，阶段0只是使用一些结构的初始约定。