|
|
面向对象编程（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等程序库，在很多地方改变了数值计算的方式。
Java和C#的一个“卖点”，就是它们的简单性。现在Java是不是快失去这个卖点了？
Stroustrup：新语言总是宣称自己如何如何简单，对老语言的复杂性颇多非议。其实这种所谓的“简单性”，简单地说，就是不成熟性。语言的复杂性，是在解决现实世界中极为烦琐和特殊的复杂问题的过程中逐渐增加的。一个语言只要活的时间够长，总会有某些地方逐渐复杂起来，或者是语言本身，或者是程序库和工具。C++和Java显然都不例外，我看C#也一样。如果一种语言能够度过自己的幼年时代，它会发现，自己无论是体积还是复杂性都大大增加了。
Lindholm：Java技术的的功能在增加，需要学习的东西也在增加。不过功能的增加并不一定带来复杂性的增加。Java技术的发展，并没有使学习曲线更加陡峭，只是让它继续向右方延展了。
标准
标准化语言和开放型语言各自的优点和缺点何在？
Lindholm：对于一个开放、不允许专有扩展、具有权威的强制性标准语言或者运行环境来说，不存在什么缺点。允许专有扩展就意味着允许厂商下套子绑架客户。特别重要的是，必须让整个平台，而不只是其中一部分完全标准化，才能杜绝厂商们利用高层次的专有API下套子。客户要求有选择厂商的自由，他们既要有创造性，又需要兼容性。
Stroustrup：对于一个语言，如C/C++来说，建立正式标准（如ISO标准）最大的好处，在于可以防止某一个厂商操纵这种语言，把它当成自己的摇钱树。多个厂商的竞争给用户带来的是较低的价位和较好的稳定性。
专有语言的好处，一是流行，二是便宜（不过等你被套牢了之后，情况就会起变化），三是对于商业性需求可以做出快速的反应。
标准化语言的特点之一是，它不能忽略特殊用户的需求。比如我在AT&T中所考虑的东西，其规模、可靠性和效率要求，跟那些普通厂商关注的大众软件相比，根本不可同日而语。那些公司很自然只关注主要的需求。
然而，多数大机构和身处前沿的公司，都有着特殊的需求。C++的设计是开放、灵活和高效的，能够满足我所能想象的任何需求。跟其他的现代语言相比，C++的家长式作风可谓少之又少，原因就在这。当然，不能赞赏这一点的人会诟病C++的“危险”。
拥有正式和开放标准的语言主要是为编程工具的使用者和客户服务的，而拥有专属“标准”的语言，主要是为厂商服务的。
|
|
|EaBIM网
( 苏ICP备2020058923号-1 ) 
苏公网安备32011502011255号
IP卡
狗仔卡
发表于 2014-1-13 17:21:21
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2016-2-23 09:39:59
发表于 2014-4-10 16:04:28
