复习 OOA、OOD、OOP

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）。方法是在收到消息后必须进行的一些处理方法：方法要在图中定义，并在对象的存储中指定。对于每一个对象和结构来说。那些用来添加、改动、删除和选择一个方法本身都是隐含的（尽管它们是要在对象的存储中定义的，但并不在图上给出）。而有些则是显示的。

OOD

　　面向对象设计（Object-Oriented Design。OOD）方法是OO方法中一个中间过渡环节。

其主要作用是对OOA分析的结果作进一步的规范化整理。以便可以被OOP直接接受。

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

　　l 决定你要的类；

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

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

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

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

　　这样的依赖关系的转换使得系统的各部分具有了可复用性。

还是拿上面那个样例来说。client就不必依赖于特定的server。所以就能够复用到其它的环境下。

假设要复用某一个程序块，仅仅要实现必须的接口即可了。

　　OOD是一种解决软件问题的设计范式（paradigm），一种抽象的范式。

使用OOD这样的设计范式，我们能够用对象（object）来表现问题领域（problem domain）的实体，每一个对象都有对应的状态和行为。我们刚才说到：OOD是一种抽象的范式。抽象能够分成许多层次。从很概括的到很特殊的都有。而对象可能处于不论什么一个抽象层次上。

另外，彼此不同但又互有关联的对象能够共同构成抽象：仅仅要这些对象之间有相似性，就能够把它们当成同一类的对象来处理。

　　一、OOD背景知识

　　计算机硬件技术却在飞速发展。从几十年前神奇的庞然大物。到如今随身携带的移动芯片。从每秒数千次运算到每秒上百亿次运算。

当软件开发人员们还在寻找能让软件开发生产力提高一个数量级的“银弹”[*s, 95]时。硬件开发的生产力早已提升了百倍千倍。

　　硬件project师们可以如此高效。是由于他们都非常懒惰。他们永远恪守“不要去又一次发明*”的古训。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年代開始大行其道。同一时候，无数的科学家和软件project师也帮助结构化方法不断发展完好，当中有非常多今天足以使我们振聋发聩的名字，比如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也会使你成为一个更好的设计师。它能提供给你非常好的工具，让你能开发出更牢固、更可维护、更可复用的软件。

OOP

　面向对象编程（Object Oriented Programming。OOP。面向对象程序设计）是一种计算机编程架构。OOP 的一条基本原则是计算机程序是由单个可以起到子程序作用的单元或对象组合而成。

OOP 达到了软件project的三个主要目标：重用性、灵活性和扩展性。为了实现总体运算，每一个对象都可以接收信息、处理数据和向其他对象发送信息。

OOP
主要有下面的概念和组件：

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

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

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

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

　　继承性 － 同意在现存的组件基础上创建子类组件，这统一并增强了多态性和封装性。典型地来说就是用类来对组件进行分组，并且还能够定义新类为现存的类的扩展，这样就能够将类组织成树形或网状结构，这体现了动作的通用性。

　　因为抽象性、封装性、重用性以及便于使用等方面的原因，以组件为基础的编程在脚本语言中已经变得特别流行。

Python 和 Ruby 是近期才出现的语言。在开发时全然採用了 OOP 的思想。而流行的 Perl 脚本语言从版本号5開始也慢慢地增加了新的面向对象的功能组件。

用组件取代“现实”上的实体成为 JavaScript（ECMAScript） 得以流行的原因。有论证表明对组件进行适当的组合就能够在英特网上取代 HTML 和 XML 的文档对象模型（DOM）。

设计模式、技术和直觉构成严峻的挑战。

这是选择编程语言之前必须认识到的，虽然不同语言的设计特性可能促进或者阻碍这一转化。

　　在网络应用的增长中。一个非常重要的部分是小型移动设备和特殊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#？

六、发展 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++的“危急”。

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