OOA:Object-Oriented Analysis面向对象分析方法

是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。OOA与结构化分析有较大的区别。OOA所强调的是

在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。

OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题

、定义属性和定义服务）组成。在这种方法中定义了两种对象类之间的结构，一种称为分类结构，一种称为组装结构。分类结构就是所谓的一

般与特殊的关系。组装结构则反映了对象之间的整体与部分的关系。

OOA在定义属性的同时，要识别实例连接。实例连接是一个实例与另一个实例的映射关系。

OOA在定义服务的同时要识别消息连接。当一个对象需要向另一对象发送消息时，它们之间就存在消息连接。

OOA 中的5个层次和5个活动继续贯穿在OOD（画向对象的设计）过程中。OOD模型由4个部分组成。它们分别是设计问题域部分、设计人机

交互部分、设计任务管理部分和设计数据管理部分。

一、OOA的主要原则：

（1）抽象：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫作抽象。抽象是形成概念的必须手段。

抽象原则有两方面的意义：第一，尽管问题域中的事物是很复杂的，但是分析员并不需要了解和描述它们的一切，只需要分析研究其中与

系统目标有关的事物及其本质性特征。第二，通过舍弃个体事物在细节上的差异，抽取其共同特征而得到一批事物的抽象概念。

抽象是面向对象方法中使用最为广泛的原则。抽象原则包括过程抽象和数据抽象两个方面。

过程抽象是指，任何一个完成确定功能的操作序列，其使用者都可以把它看作一个单一的实体，尽管实际上它可能是由一系列更低级的操

作完成的。

数据抽象是根据施加于数据之上的操作来定义数据类型，并限定数据的值只能由这些操作来修改和观察。数据抽象是OOA的核心原则。它

强调把数据（属性）和操作（服务）结合为一个不可分的系统单位（即对象），对象的外部只需要知道它做什么，而不必知道它如何做。

（2）封装就是把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。

（3）继承：特殊类的对象拥有的其一般类的全部属性与服务，称作特殊类对一般类的继承。

在OOA中运用继承原则，就是在每个由一般类和特殊类形成的一般—特殊结构中，把一般类的对象实例和所有

特殊类的对象实例都共同具

有的属性和服务，一次性地在一般类中进行显式的定义。在特殊类中不再重复地定义一般类中已定义的东西，但是在语义上，特殊类却自动地

、隐含地拥有它的一般类（以及所有更上层的一般类）中定义的全部属性和服务。继承原则的好处是：使系统模型比较简练也比较清晰。

（4）分类：就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则运用于对象描述

时的一种表现形式。

（5）聚合：又称组装，其原则是：把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。

（6）关联：是人类思考问题时经常运用的思想方法：通过一个事物联想到另外的事物。能使人发生联想的原因是事物之间确实存在着某

些联系。

（7）消息通信：这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。通过消息进行通信是

由于封装原则而引起的。在OOA中要求用消息连接表示出对象之间的动态联系。

（8）粒度控制：一般来讲，人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。因此需要控制自己的视野

：考虑全局时，注意其大的组成部分，暂时不详察每一部分的具体的细节；考虑某部分的细节时则暂时撇开其余的部分。这就是粒度控制原则

。

（9）行为分析：现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各种行为往往相互依赖、相互交织。

二、面向对象分析产生三种分析模型：

1、对象模型:对用例模型进行分析,把系统分解成互相协作的分析类,通过类图/对象图描述对象/对象的属性/对象间的关系,是系统的静态

模型

2、动态模型:描述系统的动态行为,通过时序图/协作图描述对象的交互,以揭示对象间如何协作来完成每个具体的用例,单个对象的状态变

化/动态行为可以通过状态图来表达

3、功能模型(即用例模型à作为输入)。

三、OOA的主要优点：

（1）加强了对问题域和系统责任的理解；

（2）改进与分析有关的各类人员之间的交流；

（3）对需求的变化具有较强的适应性；

（4）支持软件复用。

（5）贯穿软件生命周期全过程的一致性。

（6）实用性；

（7）有利于用户参与。

四、OOA方法的基本步骤：

在用OOA具体地分析一个事物时，大致上遵循如下五个基本步骤：

第一步，确定对象和类。这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类

是多个对象的共同属性和方

法集合的描述，它包括如何在一个类中建立一个新对象的描述。

第二步，确定结构（structure）。结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和

局部之间的关系。

第三步，确定主题（subject）。主题是指事物的总体概貌和总体分析模型。

第四步，确定属性（attribute）。属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。

第五步，确定方法（method）。方法是在收到消息后必须进行的一些处理方法：方法要在图中定义，并在对象的存储中指定。对于每个对

象和结构来说，那些用来增加、修改、删除和选择一个方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而

有些则是显示的。

OOP

目录[隐藏]

一、OOP的基本思想

二、OOP技术的历史

三、OOP 的优缺点

四、OOP的未来

五、不同OOP语言各有什么优势和劣势？

六、发展 vs. 革新

OOP: Object Oriented Programming,面向对象的程序设计

所谓“对象”就是一个或一组数据以及处理这些数据的方法和过程的集合。面向对象的程序设计完全不同于传统的 面向过程程序设计，它大大地降低了软件开发的难度，使编程就像搭积木一样简单，是当今电脑编程的一股势不可挡的潮流。

面向对象编程（Object Oriented Programming，OOP，面向对象程序设计）是一种计算机编程架构。OOP 的一条基本原则是计算机程序是由单个能够起到子程序作用的单元或对象组合而成。OOP 达到了软件工程的三个主要目标：重用性、灵活性和扩展性。为了实现整体运算，每个对象都能够接收信息、处理数据和向其它对象发送信息。OOP 主要有以下的概念和组件：

组件 － 数据和功能一起在运行着的计算机程序中形成的单元，组件在 OOP 计算机程序中是模块和结构化的基础。

抽象性 － 程序有能力忽略正在处理中信息的某些方面，即对信息主要方面关注的能力。

封装 － 也叫做信息封装：确保组件不会以不可预期的方式改变其它组件的内部状态；只有在那些提供了内部状态改变方法的组件中，才可以访问其内部状态。每类组件都提 供了一个与其它组件联系的接口，并规定了其它组件进行调用的方法。

多态性 － 组件的引用和类集会涉及到其它许多不同类型的组件，而且引用组件所产生的结果得依据实际调用的类型。

继承性 － 允许在现存的组件基础上创建子类组件，这统一并增强了多态性和封装性。典型地来说就是用类来对组件进行分组，而且还可以定义新类为现存的类的扩展，这样就 可以将

类组织成树形或网状结构，这体现了动作的通用性。

由于抽象性、封装性、重用性以及便于使用等方面的原因，以组件为基础的编程在脚本语言中已经变得特别流行。Python 和 Ruby 是最近才出现的语言，在开发时完全采用了 OOP 的思想，而流行的 Perl 脚本语言从版本5开始也慢慢地加入了新的面向对象的功能组件。用组件代替“现实”上的实体成为 JavaScript（ECMAScript）得以流行的原因，有论证表明对组件进行适当的组合就可以在英特网上代替 HTML 和 XML 的文档对象模型（DOM）。

[编辑本段]

一、OOP的基本思想

OOP的许多原始思想都来之于Simula语言，并在Smalltalk语言的完善和标准化过程中得到更多的扩展和对以前的思想的重新注解。可以说 OO 思想和OOPL几乎是同步发展相互促进的。与函数式程序设计（functional-programming）和逻辑式程序设计（logic- programming）所代表的接近于机器的实际计算模型所不同的是，OOP几乎没有引入精确的数学描叙，而是倾向于建立一个对象模型，它能够近似的反 映应用领域内的实体之间的关系，其本质是更接近于一种人类认知事物所采用的哲学观的计算模型。由此，导致了一个自然的话题，那就是OOP到底是什么？ [D&T 1988][B.S 1991] .。在OOP中，对象作为计算主体，拥有自己的名称，状态以及接受外界消息的接口。在对象模型中，产生新对象，旧对象销毁，发送消息，响应消息就构成 OOP计算模型的根本。

对象的产生有两种基本方式。一种是以原型（prototype）对象为基础产生新的对象。一种是以类（class）为基础产生新对象。原型的概念已经 在认知心理学中被用来解释概念学习的递增特性，原型模型本身就是企图通过提供一个有代表性的对象为基础来产生各种新的对象，并由此继续产生更符合实际应用 的对象。而原型-委托也是OOP中的对象抽象，代码共享机制中的一种。一个类提供了一个或者多个对象的通用性描叙。从形式化的观点看，类与类型有关，因此 一个类相当于是从该类中产生的实例的集合。而这样的观点也会带来一些矛盾，比较典型的就是在继承体系下，子集（子类）对象和父集（父类）对象之间的行为相 融性可能很难达到，这也就是OOP中常被引用的---子类型（subtype）不等于子类（subclass）[Budd 2002]。而在一种所有皆对象的世界观背景下，在类模型基础上还诞生出了一种拥有元类（metaclass）的新对象模型。即类本身也是一种其他类的对 象。以上三种根本不同的观点各自定义了三种基于类（class-based）,基于原型（prototype-based）和基于元类 （metaclass-based）的对象模型。而这三种对象模型也就导致了许多不同的

程序设计语言（如果我们暂时把静态与动态的差别放在一边）。是的， 我们经常接触的C++,Java都是使用基于类的对象模型，但除此之外还有很多我们所没有接触的OOPL采用了完全不一样的对象模型，他们是在用另外一种 观点诠释OOP的内涵。

什么是oop的基本思想呢？把组件的实现和接口分开，并且让组件具有多态性。不过，两者还是有根本的不同。oop强调在程序构造中语言要素的语法。你 必须得继承，使用类，使用对象，对象传递消息。gp不关心你继承或是不继承，它的开端是分析产品的分类，有些什么种类，他们的行为如何。就是说，两件东西 相等意味着什么？怎样正确地定义相等操作？不单单是相等操作那么简单，你往深处分析就会发现“相等”这个一般观念意味着两个对象部分，或者至少基本部分是 相等的，据此我们就可以有一个通用的相等操作。再说对象的种类。假设存在一个顺序序列和一组对于顺序序列的操作。那么这些操作的语义是什么？从复杂度权衡 的角度看，我们应该向用户提供什么样的顺序序列？该种序列上存在那些操作？那种排序是我们需要的？只有对这些组件的概念型分类搞清楚了，我们才能提到实现 的问题：使用模板、继承还是宏？使用什么语言和技术？gp的基本观点是把抽象的软件组件和它们的行为用标准的分类学分类，出发点就是要建造真实的、高效的 和不取决于语言的算法和数据结构。当然最终的载体还是语言，没有语言没法编程。stl使用 c++，你也可以用ada来实现，用其他的语言来实现也行，结果会有所不同，但基本的东西是一样的。到处都要用到二分查找和排序，而这就是人们正在做的。 对于容器的语义，不同的语言会带来轻微的不同。但是基本的区别很清楚是gp所依存的语义，以及语义分解。例如，我们决定需要一个组件swap，然后指出这 个组件在不同的语言中如果工作。显然重点是语义以及语义分类。而oop所强调的（我认为是过分强调的）是清楚的定义类之间的层次关系。oop告诉了你如何 建立层次关系，却没有告诉你这些关系的实质。

（这段不太好理解，有一些术语可能要过一段时间才会有合适的中文翻译——译者）

面向对象的编程方法OOP是九十年代才流行的一种软件编程方法。它强调对象的“抽象”、“封装”、“继承”、“多态”。我们讲程序设计是由“数据结 构”+“算法”组成的。从宏观的角度讲，OOP下的对象是以编程为中心的，是面向程序的对象。我们今天要讲的OOD是面向信息的对象，是以用户信息为中心 的。

[编辑本段]

二、OOP技术的历史

面向对象技术最初是从面向对

象的程序设计开始的，它的出现以60年代simula语言为标志。80年代中后期，面向对象程序设计逐渐成熟，被计算机界 理解和接受，人们又开始进一步考虑面向对象的开发问题。这就是九十年代以Microsoft Visual系列OOP软件的流行的背景。

传统的结构化分析与设计开发方法是一个线性过程，因此，传统的结构化分析与设计方法要求现实系统的业务管理规范，处理数据齐全，用户能全面完整地其业 务需求。

传统的软件结构和设计方法难以适应软件生产自动化的要求，因为它以过程为中心进行功能组合，软件的扩充和复用能力很差。

对象是对现实世界实体的模拟，因面能更容易地理解需求，即使用户和分析者之间具有不同的教育背景和工作特点，也可很好地沟通。

区别面向对象的开发和传统过程的开发的要素有：对象识别和抽象、封装、多态性和继承。

对象(Object)是一个现实实体的抽象，由现实实体的过程或信息牲来定义。一个对象可被认为是一个把数据（属性）和程序（方法）封装在一起的实 体，这个程序产生该对象的动作或对它接受到的外界信号的反应。这些对象操作有时称为方法。对象是个动态的概念,其中的属性反映了对象当前的状态。

类(Class)用来描述具有相同的属性和方法的对象的集合。它定义了该集合中每个对象所共有的属性和方法。对象是类的实例。

由上分析不难看出，尽管OOP技术更看中用户的对象模型，但其目的都是以编程为目的的，而不是以用户的信息为中心的，总想把用户的信息纳入到某个用户 不感兴趣的“程序对象”中。

[编辑本段]

三、OOP 的优缺点

· OOP 的优点：使人们的编程与实际的世界更加接近，所有的对象被赋予属性和方法，结果编程就更加富有人性化。

· OOP 的也有缺点，就 C++ 而言，由于面向更高的逻辑抽象层，使得 C++ 在实现的时候，不得不做出性能上面的牺牲，有时候甚至是致命的 ( 所有对象的属性都经过内置多重指针的间接引用是其性能损失的主要原因之一；不过，笔者的局限性在于未使用过 VC++ 外的面向对象语言，所以不是十分肯定，哈哈，有人笑出来了… )。

在计算机速度飞速发展的今天，你可能会说，一丁点的性能牺牲没什么大不了。是的，从面向对象的角度，使的编程的结构更加清晰完整，数据更加独立和易于 管理，性能的牺牲可以带来这么多的好处，没有理由不做稳赚的生意吧？

不过，在某些对速度要求极高特殊场合，例如你做的是电信的交换系统，每秒钟有超过百万的人同时进行电话交换，如果，每一个数据交换过程都是一个对象， 那么总的性能损失将是天文数字！！

或者这个例子不够贴身，再举个例子吧。假如你受聘于一个游戏设计公司，老板希望做出来的游戏可以更多的兼顾到更多的电脑使用者，游戏每秒钟的运行的帧 可以更多，子弹和爆炸物可以更多、更华丽。那么，你会发现使用 C++ 会使你的程序变得笨拙，无法满足你的需求，除非你非得要你的游戏运行于奔腾四的机器上 ( 如果不是，而你又坚持用 C++ 的对象编程，那么请减少主角的枪的威力吧 )。

如果你是冥顽不宁的人，你说不相信 OOP 会有性能上的损失，那么，我记得曾看到在 CSDN 上关于 VB 和 VC 执行效率的讨论的文章，讲述的就是使用了 MFC 以后，执行效率甚至低于 VB 开发出来的东西。请各位验证一下：如果使用的是纯粹的 C 语言语法的话，那么一定会比在 VB 编出来的东西要快很多 ( GetTickCount 函数可以查阅 MSDN ,如果想更加精确一些，可以使用 QueryPerformanceCounter 函数 )。

[编辑本段]

四、OOP的未来

（撰文/Bjarne Stroustrup & Tim Lindholm 编译/孟岩）

在未来三年，程序员编写代码的方式会发生那些变化？

Stroustrup: 在C++中，假如没有合适的库在背后支撑，完成任何重要的工作都可能是很复杂的。而一旦有了合适的库，任何东西都可以被我们操控于股掌之间。因此，构造和 使用程序库的重要性与日俱增。这也暗示我们，泛型程序设计(generic programming)将会越来越多地被运用。只有通过GP，我们才能确保库的通用性和高效率。我还预期在分布式计算和“组件 （components）”应用领域会出现喜人的增长。就大部分程序员而言，通过使用方便适用的程序库，这些开发工作会变得简单明了。

现在有一个趋势，编译器厂商试图把其特有的“对象模型”和图形界面(GUI)细节推销给用户。比如微软的COM和Inprise的类属性 “properties”。对于用户来说，这既不必要，也不情愿。我所希望看到的程序库，应该是用标准C++打造，界面灵活，值得信赖的程序库。通常，这 些界面应该是平台无关的。C++的表达能力极强，即使不使用大量的宏，也应该足以达成这一要求。就算有些地方无法百分之百的遵守这一原则，也应该将对于平 台和厂家的依赖性限制起来。这个目标的完成情况，可以反映软件工具产业对于应用程序开发行业的关注程度。我怀疑目前对于那些独立的、跨平台厂商来说，并不 存在相应的市场。如果能够建立这样的市场，也许能够促进厂商们为客户做出“真正有用的”产品。

Lindholm: 对于编写代码的开发者来说，主要的驱动力量仍将是两个：网络和分布式——也就是设计和开发非单机软件的需求。大部分的应用程序将不会是孤零零地运行在单一 设备上

，而是运用了类似EJB和JSP之类技术的，平台无关的分布式程序。程序员们将不得不面对分布式计算的重重险阻。这将对许多程序员所依赖的设计模 式、技术和直觉构成严峻的挑战。这是选择编程语言之前必须认识到的，尽管不同语言的设计特性可能促进或者阻碍这一转化。

在网络应用的增长中，一个很重要的部分是小型移动设备和特殊Internet设备的爆炸性增长。这些设备各有各的操作系统，或者只在某种特定的设备领 域内有共同的操作系统。我们现在还可以一一列举出这些设备——家庭接入设备、蜂窝电话、电子报纸、PDA、自动网络设备等等。但是这些设备领域的数量和深 入程度将会很快变得难以估量。我们都知道这个市场大得惊人，PC的兴起与之相比不过小菜一碟。因此在这些设备的应用程序市场上，竞争将会相当残酷。获胜的 重要手段之一，就是尽快进入市场。开发人员需要优秀的工具，迅速高效地撰写和调试他们的软件。平台无关性也是制胜秘诀之一，它使得程序员能够开发出支持多 种设备平台的软件。

我预期的另一个变化是，我们对于代码(Java)和数据(XML)协同型应用程序的开发能力将会不断提高。这种协同是开发强大应用程序的核心目标之 一。我们从XML的迅速流行和ebXML规范的进展中，已经看到了这个趋势。ebXML是一个针对电子商务和国际贸易的，基于XML的开放式基础构架，由 联合国贸易促进和电子商务中心(UN/CEFACT)与结构性信息标准推进组织(OASIS)共同开发。

我们能否期望出现一个真正的面向组件(component-oriented)的语言？它的创造者会是谁呢？

Stroustrup: 我怀疑，这个领域中之所以缺乏成果，正是因为人们——主要是那些非程序员们——对“组件”这个意义含糊的字眼寄予了太多的期望。这些人士梦想，有朝一日， 组件会以某种方式把程序员赶出历史舞台。以后那些称职的“设计员”只需利用预先调整好的组件，把鼠标拖一拖放一放，就把系统组合出来。对于软件工具厂商来 说，这种想法还有另一层意义，他们认为，到时候只有他们才保留有必要的技术，有能力编写这样的组件。

这种想法有一个最基本的谬误：这种组件很难获得广泛欢迎。一个单独的组件或框架 (framework)，如果能够满足一个应用程序或者一个产业领域对所提出的大部分要求的话，对于其制造者来说就是划算的产品，而且技术上也不是很困 难。可是该产业内的几个竞争者很快就会发现，如果所有人都采用这些组件，那么彼此之间的产品就会变得天下大同，没什么区别，他们将沦为简单的办事员，主要 利润都将钻进那些组件/框架供应商的腰包里！

小“组件”很有用，不过产生不了预期的杠杆效应。中型的、更通用的组件非常有用，但是构造时需要非同寻常的弹性。

在C++中，我们综合运用不同共享形式的类体系(class hierarchies)，以及使用templates精心打造的接口，在这方面取得了一定的进展。我期待在这个领域取得一些有趣和有用的成果，不过我认 为这种成果很可能是一种新的C++程序设计风格，而不是一种新的语言。

Lindholm: 编写面向组件的应用程序，好像更多的是个投资、设计和程序员管理方面的问题，而不是一个编程语言问题。当然某些语言在这方面具有先天优势，不过如果说有什 么魔术般的新语言能够大大简化组件的编写难度，那纯粹是一种误导。

微软已经将全部赌注押在C#上，其他语言何去何从？

Stroustrup: C++在下一个十年里仍然将是一种主流语言。面对新的挑战，它会奋起应对。一个创造了那么多出色系统的语言，绝不会“坐视落花流水春去也”。

我希望微软认识到，它在C++(我指的是ISO标准C++)上有着巨大的利益，C++是它与IT世界内其他人之间的一座桥梁，是构造大型系统和嵌入式 系统的有效工具，也是满足高性能需求的利器。其他语言，似乎更注重那些四平八稳的商用程序。

竞争

C#会不会获得广泛的接受，并且挤掉其他的语言？

Lindholm: 通常，一种语言既不会从别的语言那里获利，也不会被挤掉。那些坚定的Fortran程序员不还用着Fortran吗？对于个人来说，语言的选择当然因时而 异，但就整体而言，语言的种类只会递增，也就是说，它们之间的关系是“有你有我”而不是“有你没我”。

对于一个新语言的接受程度，往往取决于其能力所及。Java技术被迅速接受，原因是多方面的，Internet和World Wide Web接口，在其他技术面前的挫折感，对于Java技术发展方向的全面影响能力，都是原因。另一个重要的原因是Java独立于厂商，这意味着在兼容产品面 前可以从容选择。

C#是否会获得广泛接受？视情况而定。总的来说，那些对于平台无关性和厂商无关性漠不关心的程序员，可能会喜欢C#。那些跟微软平台捆在一起人当然可 能想要寻找VB 和VC的一个出色的替代品。但是对于程序跨平台执行能力特别关注的程序员，将会坚守Java之类的语言。这种能力对于多重访问设备（multiple access devices）和分布式计算模型至关重要，而Java语言提供了一个标准的、独立于厂商运行时环境。

Stroustrup:C#的流行程度几乎完全取决于微软投入的资金多少。看上去C#的兴起肯定会牺牲掉其他一些语言的利益，但是事实上未必如此。 Java的蓬勃发展并没有给C++带来衰败。C++的应用仍然在稳定增长（当然，

已经不是爆炸性的增长了）。也许其他的语言也还能获得自己的一席之地。

不过，我实在看不出有什么必要再发明一种新的专有语言。特别是微软，既生VB，何需C#？

[编辑本段]

五、不同OOP语言各有什么优势和劣势？

Stroustrup: C++的优点自始至终都是这么几条：灵活、高效，而且并非专有语言。现在ISO C++标准的出现，巩固了最后一点。

我认为C++的高效是它最基本的优点。这种高效来自于其特有的数据和计算模型，较之Java和 C#，这种模型更加贴近机器。不过，哪些程序才真正地渴望这么高的效率？这是个问题。我认为这类程序非常多。人们对于计算机的期望，永远都超越硬件科技的 发展速度。很显然，Java和C#的设计者的想法不同，他们认为，在很多地方效率问题无关紧要。

C++主要的缺点，归罪于糟糕的教育（是那些始终认为C++是个纯粹面向对象语言的人，和那些把C++当成C语言变体的人导致了这种情况），归罪于不 同平台上的不一致性，归罪于不完整、不标准的编译器实现，归罪于平台无关的系统级程序库的缺少。

这些问题归于一点，就是缺乏一个卓越的厂商，能够满足整个C++社区的需求，勇于投入大量的资金开发必要的程序库。

Lindholm: Java技术的成功，是因为它在合适的时间，出现在合适的地点，而且合理地选择了语言和计算平台的支持目标。Java并不是在所有场合都优于其他OOP语 言，但是对于出现的新问题能够解决得很出色。它面向Internet计算环境，避免了C++中晦涩的结构，成功翻越了继承机制的恼人问题。垃圾收集机制显 著地提高了生产率，降低了复杂度。在网络背景下使用虚拟机，以及有关安全性和动态加载的一系列设计选择，迎合了正在出现的需求和愿望。这些特性使Java 不仅成为现有程序员的新武器，而且也为新的程序员创造了繁荣的市场空间。

此外，Java拥有一个标准化的、二进制形式的类库，提供了必要的（当然并非充分的）平台与厂商无关性。平台与厂商无关性要求一项技术必须有清晰的规 范，摒弃那些阻碍二进制标准实施的特性。C++虽然有一个ISO标准，但其实甚至对于相同系统与相同指令体系的各个平台，也提不出一个实用的、各版本兼容 的二进制标准。

历史上很多使用虚拟机的语言饱受责难，是因为其不够出色的性能问题，而这要归过于缓慢的解释器和糟糕的垃圾收集器。Java的早期实现也因为同样的问 题受到严厉的批评。但是自那时起，业界向新的虚拟机实现技术投入了大量资金，取得了显著的效果，如今在大部分场合，Java的性能跟常规的静态编译语言相 比毫不逊色。这使得程序员在获得平台

和厂商无关性的同时，也不必付出性能上的代价。

C++并没有强制使用面向对象方法，因此为了编写出色的面向对象代码，就要求程序员们有相当强的纪律性。很多公司就是因为这个原因放弃了C++。作为 语言，Java的一个突出的优点就是强制面向对象方法，不允许非面向对象的结构。

C#介于C++和Java之间，脚踏两只船，因此既不够安全，又失之复杂。

对于公司来说，采用新的语言要付出巨大代价。雇不到好的程序员（没人熟悉这种新语言），培训费用高得惊人，学习过程中生产率和产品质量下降，多年的经 验随风消逝，等等。一种语言如何克服这些障碍？

Lindholm: 说得很对，采用新东西确实常常开销巨大。不过问题是：这个新东西是否能够节省更多的开支，或者提供巨大的改进，获取合理的回报？很多公司发现，转向 Java技术不论在开发的后端（尽快进入市场、快速迭代开发、维护简单性）还是前端（跨平台发布，适用范围从低端设备到高端服务器的技术，安全性），都能 节省大笔的开销。

对于新事物的接纳，常常是在痛楚的压力之下。很大程度上，这正是Java所经历的。Java的产生，是对当时很多系统的缺陷所做出的反应。Java技 术通过下面的手段减轻了开发者的痛楚：1) 顾及了网络计算方面的需求，是应运而生。2) 在技术能力的抉择上，保持良好的品位，顾及了大众的心理。3) 采用适度强制性策略推行设计决定。此外，Java技术已经成为大学教学中的主流，这同样保证了Java开发者队伍的不断壮大。

但是最重要的一点是，再没有另一种程序设计技术，能够像Java那样允许程序员开发基于 Internet的不同平台之上的应用程序。Java平台在这方面的杰出表现，已经被大量的实例证明。Java已经成为Internet上的缺省应用程序 平台，Java APIs也成为Internet应用程序开发的天然平台。

Stroustrup: 微软和Sun把大笔的金钱扔在Java、VB和C#中，并不是因为他良心发现，也不是因为他们真的相信这些语言能够带给程序员更美好的生活，而是利益使 然。

有一个说法，认为软件工具厂商如果能够把应用程序开发者的专业技术任务负担起来，将获取巨大的经济利益。我对其背后的经济分析颇为怀疑，我认为这很难 成为现实，特别是当应用程序开发者使用开放的、标准化的工具时，他们可以有多种选择，从而使上面的想法更加不可能。

多年以前，C++就已经具有泛型能力(也就是templates和STL)，有运算符重载，有枚举类型？我们会不会在Java的未来版本中看到这些特 性？Java是不是应该纳入这些特性呢？

Strousturp:从1988-89年起，C++就已经有了templates。但是我们花了不少时

间来了解如何最好地运用这个工具，早期各厂家 对于template的支持在品质上也有很大的差异。有些编译器厂商动作迟缓，至少有一个主要的编译器厂商（好像是指微软，微软在Visual C++4.0才开始支持template，在此之前一直声称template是过于复杂而又没什么用的技术，时至今日，Visual C++对于template的支持在主流编译器中都属于最差的一档——译者注）暗中鼓励声名狼藉的反template宣传，直到他们自己终于学会了这项技 术为止。直到今天，对于template的支持在品质上仍然有待改进。

你上面提到的那些特性，我认为Java（还有C#）应该，也肯定会逐渐引入。那些对于程序员来说最有用的语言特性和概念，将会逐渐集中，成为各家主流 语言的必然之选。也就是说，我认为类似析构函数和模板特殊化之类的机制，远远比枚举等机制重要得多。

Lindholm：Java技术成功的原因之一，就是很清楚哪些不该做。我们得多问几个为什么：这项特性是不是必不可少？增加它会带来哪些开销？运算 符重载是C++中一项极其强大的特性，但是它也大大增加了C++语言的复杂度，很多人都难以招架。Java在各种可能的权衡之中，做出了明智的抉择，找到 了能力与需求之间的完美平衡点。

当然，Java也会发展，而且最重要的是，现在是开发者们在推动发展。Java增加泛型能力这件事，很好地展示了Java是如何通过整个开发者社群的 参与，在权衡中决定正确的平衡点。关于增加泛型类型（generic types）的“Java规格申请”（Java Specification Request, JSR）已经进入JCP（Java Community Process）程序，而且已经开发了很长一段时间（参见 http://java.sun.com/aboutJava/communityprocess/之JSR-014）。现在，在JCP中，有超过80个 JSRs正在讨论中，这充分体现了整个体系对开发者的积极反馈和高度合作，这正是驱动Java平台不断进化的动力。

[编辑本段]

六、发展 vs. 革新

(Evolution vs. Revolution)

C++是一种发展型的语言，Java和C#似乎更像是革新型语言（它们是从头设计的）？什么时候，革新型的语言才是必需的呢？

Lindholm: Java技术并非凭空出世，反而更像是发展型的。Java所有的特性，在Java平台推出之前，都至少已经存在于另一种环境之中。Java的贡献在于，在 众多的特性和权衡中，做出了合理的选择，使得产品既实用，又优雅。Java技术对于程序员的态度是：抚养，但不溺爱。

Stroustrup：从技术上讲，我并不认为Java和C#是什么“从头设计的”革新型语言。倘若Java是从技术原则出发，从头设计，大概就不会 模仿C/C++那种丑陋和病态的语法了（不必惊讶，Stroustrup在很多场合表示过，C++采用C的语法形式，实在是迫于兼容性

。他本人更偏爱 Simula的语法——译者）。

我认为，只有当程序员们面对的问题发生了根本的变化的时候，或者当我们发现了全新的、极其优越的程序设计技术，又完全不能为现存语言所支持的时候，我 们才需要全新的语言。问题是，我们恐怕永远也碰不到那些“根本”、“全新”的情况。

我以为，自从OOP问世以来，可称为“根本”的新型程序设计技术，唯有泛型程序设计（generic programming）和生成式程序设计（generative programming）技术，这两项技术主要是源于C++ templates技术的运用，也有一部分曾经被视为面向对象和函数式语言(functional languages)的次要成分，现在都变成正式、可用和可承受的技术了。我对于目前C++模板(template)程序设计的成果非常兴奋。例如，像 POOMA, Blitz++和MTL等程序库，在很多地方改变了数值计算的方式。

C#的一个“卖点”，就是它们的简单性。现在Java是不是快失去这个卖点了？

Stroustrup：新语言总是宣称自己如何如何简单，对老语言的复杂性颇多非议。其实这种所谓的“简单性”，简单地说，就是不成熟性。语言的复杂 性，是在解决现实世界中极为烦琐和特殊的复杂问题的过程中逐渐增加的。一个语言只要活的时间够长，总会有某些地方逐渐复杂起来，或者是语言本身，或者是程 序库和工具。C++和Java显然都不例外，我看C#也一样。如果一种语言能够度过自己的幼年时代，它会发现，自己无论是体积还是复杂性都大大增加了。

Lindholm：Java技术的的功能在增加，需要学习的东西也在增加。不过功能的增加并不一定带来复杂性的增加。Java技术的发展，并没有使学 习曲线更加陡峭，只是让它继续向右方延展了。

标准

标准化语言和开放型语言各自的优点和缺点何在？

Lindholm：对于一个开放、不允许专有扩展、具有权威的强制性标准语言或者运行环境来说，不存在什么缺点。允许专有扩展就意味着允许厂商下套子 绑架客户。特别重要的是，必须让整个平台，而不只是其中一部分完全标准化，才能杜绝厂商们利用高层次的专有API下套子。客户要求有选择厂商的自由，他们 既要有创造性，又需要兼容性。

Stroustrup：对于一个语言，如C/C++来说，建立正式标准（如ISO标准）最大的好处，在于可以防止某一个厂商操纵这种语言，把它当成自 己的摇钱树。多个厂商的竞争给用户带来的是较低的价位和较好的稳定性。

专有语言的好处，一是流行，二是便宜（不过等你被套牢了之后，情况就会起变化），三是对于商业性需求可以做出快速的反应。

标准化语言的特点之一是，它不能忽略特殊用户的需求。比如我在AT&T中所考虑的

东西，其规模、可靠性和效率要求，跟那些普通厂商关注的大众 软件相比，根本不可同日而语。那些公司很自然只关注主要的需求。

然而，多数大机构和身处前沿的公司，都有着特殊的需求。C++的设计是开放、灵活和高效的，能够满足我所能想象的任何需求。跟其他的现代语言相 比，C++的家长式作风可谓少之又少，原因就在这。当然，不能赞赏这一点的人会诟病C++的“危险”。

拥有正式和开放标准的语言主要是为编程工具的使用者和客户服务的，而拥有专属“标准”的语言，主要是为厂商服务的。

OOD

面向对象设计（Object-Oriented Design，OOD）方法是OO方法中一个中间过渡环节。其主要作用是对OOA分析的结果作进一步的规范化整理，以便能够被OOP直接接受。

面向对象设计（OOD）是一种软件设计方法，是一种工程化规范。这是毫无疑问的。按照Bjarne Stroustrup的说法，面向对象的编程范式（paradigm）是[Stroustrup, 97]：

l 决定你要的类；

l 给每个类提供完整的一组操作；

l 明确地使用继承来表现共同点。

由这个定义，我们可以看出：OOD就是“根据需求决定所需的类、类的操作以及类之间关联的过程”。

OOD的目标是管理程序内部各部分的相互依赖。为了达到这个目标，OOD要求将程序分成块，每个块的规模应该小到可以管理的程度，然后分别将各个块隐 藏在接口（interface）的后面，让它们只通过接口相互交流。比如说，如果用OOD的方法来设计一个服务器-客户端（client-server） 应用，那么服务器和客户端之间不应该有直接的依赖，而是应该让服务器的接口和客户端的接口相互依赖。

这种依赖关系的转换使得系统的各部分具有了可复用性。还是拿上面那个例子来说，客户端就不必依赖于特定的服务器，所以就可以复用到其他的环境下。如果 要复用某一个程序块，只要实现必须的接口就行了。

OOD是一种解决软件问题的设计范式（paradigm），一种抽象的范式。使用OOD这种设计范式，我们可以用对象（object）来表现问题领域 （problem domain）的实体，每个对象都有相应的状态和行为。我们刚才说到：OOD是一种抽象的范式。抽象可以分成很多层次，从非常概括的到非常特殊的都有，而 对象可能处于任何一个抽象层次上。另外，彼此不同但又互有关联的对象可以共同构成抽象：只要这些对象之间有相似性，就可以把它们当成同一类的对象来处理。

一、OOD背景知识

计算机硬件技术却在飞速发展。从几十年前神秘的庞然大物，到现在随身携带的移动芯片；从每秒数千次运算到每秒上百亿次运算。当软件开发者们还在寻找能 让软件开发生产力提

高一个数量级的“银弹”[Brooks, 95]时，硬件开发的生产力早已提升了百倍千倍。

硬件工程师们能够如此高效，是因为他们都很懒惰。他们永远恪守“不要去重新发明轮子”的古训。Grady Booch把这些黑箱称为类属（class category），现在我们则通常把它们称为“组件（component）”。

类属是由被称为类（class）的实体组成的，类与类之间通过关联（relationship）结合在一起。一个类可以把大量的细节隐藏起来，只露出 一个简单的接口，这正好符合人们喜欢抽象的心理。所以，这是一个非常伟大的概念，因为它给我们提供了封装和复用的基础，让我们可以从问题的角度来看问题， 而不是从机器的角度来看问题。

软件的复用最初是从函数库和类库开始的，这两种复用形式实际上都是白箱复用。到90年代，开始有人开发并出售真正的黑箱软件模块：框架 （framework）和控件（control）。框架和控件往往还受平台和语言的限制，现在软件技术的新潮流是用SOAP作为传输介质的Web Service，它可以使软件模块脱离平台和语言的束缚，实现更高程度的复用。但是想一想，其实Web Service也是面向对象，只不过是把类与类之间的关联用XML来描述而已[Li, 02]。

在过去的十多年里，面向对象技术对软件行业起到了极大的推动作用。在可以预测的将来，它仍将是软件设计的主要技术——至少我看不到有什么技术可以取代 它的。

二、OOD到底从哪儿来？

有很多人都认为：OOD是对结构化设计（Structured Design，SD）的扩展，其实这是不对的。OOD的软件设计观念和SD完全不同。SD注重的是数据结构和处理数据结构的过程。而在OOD中，过程和数 据结构都被对象隐藏起来，两者几乎是互不相关的。不过，追根溯源，OOD和SD有着非常深的渊源。

1967年前后，OOD和SD 的概念几乎同时诞生，它们分别以不同的方式来表现数据结构和算法。当时，围绕着这两个概念，很多科学家写了大量的论文。其中，由Dijkstra和 Hoare两人所写的一些论文讲到了“恰当的程序控制结构”这个话题，声称goto语句是有害的，应该用顺序、循环、分支这三种控制结构来构成整个程序流 程。这些概念发展构成了结构化程序设计方法；而由Ole-Johan Dahl所写的另一些论文则主要讨论编程语言中的单位划分，其中的一种程序单位就是类，它已经拥有了面向对象程序设计的主要特征。

这两种概念立刻就分道扬镳了。在结构化这边的历史大家都很熟悉：NATO会议采纳了 Dijkstra的思想，整个软件产业都同意goto语句的确是有害的，结构化方法、瀑布模型从70年代开始大行其道。同时，无数的科学家和软件工程师也 帮助结构化方法不

断发展完善，其中有很多今天足以使我们振聋发聩的名字，例如Constantine、Yourdon、DeMarco和 Dijkstra。有很长一段时间，整个世界都相信：结构化方法就是拯救软件工业的 “银弹”。当然，时间最后证明了一切。

而此时，面向对象则在研究和教育领域缓慢发展。结构化程序设计几乎可以应用于任何编程语言之上，而面向对象程序设计则需要语言的支持[1]，这也妨碍 了面向对象技术的发展。实际上，在60年代后期，支持面向对象特性的语言只有Simula-67 这一种。到70年代，施乐帕洛阿尔托研究中心（PARC）的 Alan Key等人又发明了另一种基于面向对象方法的语言，那就是大名鼎鼎的Smalltalk。但是，直到80年代中期，Smalltalk和另外几种面向对象 语言仍然只停留在实验室里。

到90年代，OOD突然就风靡了整个软件行业，这绝对是软件开发史上的一次革命。不过，登高才能望远，新事物总是站在旧事物的基础之上的。70年代和 80年代的设计方法揭示出许多有价值的概念，谁都不能也不敢忽视它们，OOD也一样。

三、OOD和传统方法有什么区别？

还记得结构化设计方法吗？程序被划分成许多个模块，这些模块被组织成一个树型结构。这棵树的根就是主模块，叶子就是工具模块和最低级的功能模块。同 时，这棵树也表示调用结构：每个模块都调用自己的直接下级模块，并被自己的直接上级模块调用。

那么，哪个模块负责收集应用程序最重要的那些策略？当然是最顶端的那些。在底下的那些模块只管实现最小的细节，最顶端的模块关心规模最大的问题。所 以，在这个体系结构中越靠上，概念的抽象层次就越高，也越接近问题领域；体系结构中位置越低，概念就越接近细节，与问题领域的关系就越少，而与解决方案领 域的关系就越多。

但是，由于上方的模块需要调用下方的模块，所以这些上方的模块就依赖于下方的细节。换句话说，与问题领域相关的抽象要依赖于与问题领域无关的细节！这 也就是说，当实现细节发生变化时，抽象也会受到影响。而且，如果我们想复用某一个抽象的话，就必须把它依赖的细节都一起拖过去。

而在OOD中，我们希望倒转这种依赖关系：我们创建的抽象不依赖于任何细节，而细节则高度依赖于上面的抽象。这种依赖关系的倒转正是OOD和传统技术 之间根本的差异，也正是OOD思想的精华所在。

四、OOD步骤

细化重组类

细化和实现类间关系,明确其可见性

增加属性,指定属性的类型与可见性

分配职责,定义执行每个职责的方法

对消息驱动的系统,明确消息传递方式

利用设计模式进行局部设计

画出详细的类图与时序图

五、OOD设计过程中要展开的主要几项工作

（一）对象定义规格的求精过程

对于OOA所抽象出来的对象-＆-类以及汇集的分析文档，OOD需要有一个根据设计要求整理和求精的过程，使之更能符合OOP的需要。这个整理和求精 过程主要有两个方面：一是要根据面向对象的概念

模型整理分析所确定的对象结构、属性、方法等内容，改正错误的内容，删去不必要和重复的内容等。二是进行分类整理，以便于下一步数据库设计和程序处理 模块设计的需要。整理的方法主要是进行归

类，对类一＆一对象、属性、方法和结构、主题进行归类。

（二）数据模型和数据库设计

数据模型的设计需要确定类-＆-对象属性的内容、消息连接的方式、系统访问、数据模型的方法等。最后每个对象实例的数据都必须落实到面向对象的库结构 模型中。

（三）优化

OOD的优化设计过程是从另一个角度对分析结果和处理业务过程的整理归纳，优化包括对象和结构的优化、抽象、集成。

对象和结构的模块化表示OOD提供了一种范式，这种范式支持对类和结构的模块化。这种模块符合一般模块化所要求的所有特点，如信息隐蔽性好，内部聚合 度强和模块之间耦合度弱等。

集成化使得单个构件有机地结合在一起，相互支持。

六、OO方法的特点和面临的问题

OO方法以对象为基础，利用特定的软件工具直接完成从对象客体的描述到软件结构之间的转换。这是OO方法最主要的特点和成就。OO方法的应用解决了传 统结构化开发方法中客观世界描述工具与软

件结构的不一致性问题，缩短了开发周期，解决了从分析和设计到软件模块结构之间多次转换映射的繁杂过程，是一种很有发展前途的系统开发方法。

但是同原型方法一样,OO方法需要一定的软件基础支持才可以应用，另外在大型的MIS开发中如果不经自顶向下的整体划分，而是一开始就自底向上的采用 OO 方法开发系统，同样也会造成系统结构不合理、各部分关系失调等问题。所以OO方法和结构化方法目前仍是两种在系统开发领域相互依存的、不可替代的方法。

七、OOD能给我带来什么？

问这个问题的人，脑子里通常是在想“OOD能解决所有的设计问题吗？”没有银弹。OOD也不是解决一切设计问题、避免软件危机、捍卫世界和平……的银 弹。OOD只是一种技术。但是，它是一种优秀的技术，它可以很好地解决目前的大多数软件设计问题 ——当然，这要求设计者有足够的能力。

OOD可能会让你头疼，因为要学会它、掌握它是很困难的；OOD甚至会让你失望，因为它也并不成熟、并不完美。OOD也会给你带来欣喜，它让你可以专 注于设计，而不必

操心那些细枝末节；OOD也会使你成为一个更好的设计师，它能提供给你很好的工具，让你能开发出更坚固、更可维护、更可复用的软件。