關于OOP的文章已經跟多了，但是還是禁不住把這篇文章轉到這里，以讓大家從各方面來了解和認識面向對象。本文從面相對象的基本概念說起，探討了面向對象的的特點，發展以及C++、Java和C#這些面向對象語言的發展與競爭情況。

OOP: Object Oriented Program命,面向對象的程序設計。所謂“對象”就是一個或一組數據以及處理這些數據的方法和過程的集合。面向對象的程序設計完全不同于傳統的面向過程程序設計，它大大地降低了軟件開發的難度，使編程就像搭積木一樣簡單，是當今電腦編程的一股勢不可擋的潮流。

面向對象編程（Object Oriented Program命，OOP，面向對象程序設計）是一種計算機編程架構。OOP 的一條基本原則是計算機程序是由單個能夠起到子程序作用的單元或對象組合而成。OOP 達到了軟件工程的三個主要目標：重用性、靈活性和擴展性。為了實現整體運算，每個對象都能夠接收信息、處理數據和向其它對象發送信息。OOP 主要有以下的概念和組件：

組件 － 數據和功能一起在運行著的計算機程序中形成的單元，組件在 OOP 計算機程序中是模塊和結構化的基礎。

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

封裝 － 也叫做信息封裝：確保組件不會以不可預期的方式改變其它組件的內部狀態；只有在那些提供了內部狀態改變方法的組件中，才可以訪問其內部狀態。每類組件都提供了一個與其它組件聯系的接口，并規定了其它組件進行調用的方法。

多態性 － 組件的引用和類ji hui涉及到其它許多不同類型的組件，而且引用組件所產生的結果得依據實際調用的類型。

繼承性 － 允許在現存的組件基礎上創建子類組件，這統一并增強了多態性和封裝性。典型地來說就是用類來對組件進行分組，而且還可以定義新類為現存的類的擴展，這樣就可以將類組織成樹形或網狀結構，這體現了動作的通用性。

由于抽象性、封裝性、重用性以及便于使用等方面的原因，以組件為基礎的編程在腳本語言中已經變得特別流行。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++程序設計風ge，而不是一種新的語言。

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 program命）和生成式程序設計（generative program命）技術，這兩項技術主要是源于C++ templates技術的運用，也有一部分曾經被視為面向對象和函數式語言(functional languages)的次要成分，現在都變成正式、可用和可承受的技術了。我對于目前C++模板(template)程序設計的成果非常興奮。例如，像POOMA, Blitz++和MTL等程序庫，在很多地方改變了數值計算的方式。

C#的一個“賣點”，就是它們的簡單性。現在Java是不是快失去這個賣點了？

Stroustrup：新語言總是宣稱自己如何如何簡單，對老語言的復雜性頗多非議。其實這種所謂的“簡單性”，簡單地說，就是不成熟性。語言的復雜性，是在解決現實世界中極為煩瑣和特殊的復雜問題的過程中逐漸增加的。一個語言只要活的時間夠長，總會有某些地方逐漸復雜起來，或者是語言本身，或者是程序庫和工具。C++和Java顯然都不例外，我看C#也一樣。如果一種語言能夠度過自己的幼年時代，它會發現，自己無論是體積還是復雜性都大大增加了。

Lindholm：Java技術的的功能在增加，需要學習的東西也在增加。不過功能的增加并不一定帶來復雜性的增加。Java技術的發展，并沒有使學習曲線更加陡峭，只是讓它繼續向右方延展了。

標準　　標準化語言和開放型語言各自的優點和缺點何在？

Lindholm：對于一個開放、不允許專有擴展、具有權威的強制性標準語言或者運行環境來說，不存在什么缺點。允許專有擴展就意味著允許廠商下套子綁架客戶。特別重要的是，必須讓整個平臺，而不只是其中一部分完全標準化，才能杜絕廠商們利用高層次的專有API下套子。客戶要求有選擇廠商的zi you，他們既要有創造性，又需要兼容性。

Stroustrup：對于一個語言，如C/C++來說，建立正式標準（如ISO標準）最大的好處，在于可以防止某一個廠商操縱這種語言，把它當成自己的搖錢樹。多個廠商的競爭給用戶帶來的是較低的價位和較好的穩定性。

專有語言的好處，一是流行，二是便宜（不過等你被套牢了之后，情況就會起變化），三是對于商業性需求可以做出快速的反應。

標準化語言的特點之一是，它不能忽略特殊用戶的需求。比如我在AT&T中所考慮的東西，其規模、可靠性和效率要求，跟那些普通廠商關注的大眾軟件相比，根本不可同日而語。那些公司很自然只關注主要的需求。

然而，多數大機構和身處前沿的公司，都有著特殊的需求。C++的設計是開放、靈活和高效的，能夠滿足我所能想象的任何需求。跟其他的現代語言相比，C++的家長式作風可謂少之又少，原因就在這。當然，不能贊賞這一點的人會詬病C++的“危險”。

擁有正式和開放標準的語言主要是為編程工具的使用者和客戶服務的，而擁有專屬“標準”的語言，主要是為廠商服務的。