⾯向对象的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）是⼀种软件设计⽅法，是⼀种⼯程化规范。这是毫⽆疑问的。按照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也会使你成为⼀个更好的设计师，它能提供给你很好的⼯具，让你能开发出更坚固、更可维护、更可复⽤的软件。
OOP
　（Object Oriented Programming，OOP，⾯向对象程序设计）是⼀种计算机编程架构。OOP 的⼀条基本原则是计算机程序是由单个能够起到⼦程序作⽤的单元或对象组合⽽成。OOP 达到了软件⼯程的三个主要⽬标：重⽤性、灵活性和扩展性。为了实现整体运算，每个对象都能够接收信息、处理数据和向其它对象发送信息。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)

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。