接著來看OOP。OOP的未來在未來三年，程序員編寫代碼的方式會發生那些變化？
Stroustrup：在C++中，假如沒有合適的庫在背后支撐，完成任何重要的工作都可能是很復雜的。而一旦有了合適的庫，任何東西都可以被我們操控于股掌之間。因此，構造和使用程序庫的重要性與日俱增。這也暗示我們，泛型程序設計（genericprogramming）將會越來越多地被運用。只有通過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），如果能夠滿足一個應用程序或者一個產業領域對所提出的大部分要求的話，對于其制造者來說就是劃算的產品，而且技術上也不是很困難?？墒窃摦a業內的幾個競爭者很快就會發現，如果所有人都采用這些組件，那么彼此之間的產品就會變得天下大同，沒什么區別，他們將淪為簡單的辦事員，主要利潤都將鉆進那些組件/框架供應商的腰包里！
小“組件”很有用，不過產生不了預期的杠桿效應。中型的、更通用的組件非常有用，但是構造時需要非同尋常的彈性。
在C++中，我們綜合運用不同共享形式的類體系（classhierarchies），以及使用templates精心打造的接口，在這方面取得了一定的進展。我期待在這個領域取得一些有趣和有用的成果，不過我認為這種成果很可能是一種新的C++程序設計風格，而不是一種新的語言。
Lindholm：編寫面向組件的應用程序，好像更多的是個投資、設計和程序員管理方面的問題，而不是一個編程語言問題。當然某些語言在這方面具有先天優勢，不過如果說有什么魔術般的新語言能夠大大簡化組件的編寫難度，那純粹是一種誤導。
微軟已經將全部賭注押在C#上，其他語言何去何從？
Stroustrup：C++在下一個十年里仍然將是一種主流語言。面對新的挑戰，它會奮起應對。一個創造了那么多出色系統的語言，絕不會“坐視落花流水春去也”。
我希望微軟認識到，它在C++（我指的是ISO標準C++）上有著巨大的利益，C++是它與IT世界內其他人之間的一座橋梁，是構造大型系統和嵌入式系統的有效工具，也是滿足高性能需求的利器。其他語言，似乎更注重那些四平八穩的商用程序。
競爭
C#會不會獲得廣泛的接受，并且擠掉其他的語言？
Lindholm：通常，一種語言既不會從別的語言那里獲利，也不會被擠掉。那些堅定的Fortran程序員不還用著Fortran嗎？對于個人來說，語言的選擇當然因時而異，但就整體而言，語言的種類只會遞增，也就是說，它們之間的關系是“有你有我”而不是“有你沒我”。
對于一個新語言的接受程度，往往取決于其能力所及。Java技術被迅速接受，原因是多方面的，Internet和WorldWideWeb接口，在其他技術面前的挫折感，對于Java技術發展方向的全面影響能力，都是原因。另一個重要的原因是Java獨立于廠商，這意味著在兼容產品面前可以從容選擇。
C#是否會獲得廣泛接受？視情況而定。總的來說，那些對于平臺無關性和廠商無關性漠不關心的程序員，可能會喜歡C#。那些跟微軟平臺捆在一起人當然可能想要尋找VB和VC的一個出色的替代品。但是對于程序跨平臺執行能力特別關注的程序員，將會堅守Java之類的語言。這種能力對于多重訪問設備（multipleaccessdevices）和分布式計算模型至關重要，而Java語言提供了一個標準的、獨立于廠商運行時環境。
Stroustrup：C#的流行程度幾乎完全取決于微軟投入的資金多少?？瓷先#的興起肯定會犧牲掉其他一些語言的利益，但是事實上未必如此。Java的蓬勃發展并沒有給C++帶來衰敗。C++的應用仍然在穩定增長（當然，已經不是爆炸性的增長了）。也許其他的語言也還能獲得自己的一席之地。
不過，我實在看不出有什么必要再發明一種新的專有語言。特別是微軟，既生VB，何需C#？
不同OOP語言各有什么優勢和劣勢？
Stroustrup：C++的優點自始至終都是這么幾條：靈活、高效，而且并非專有語言。現在ISOC++標準的出現，鞏固了最后一點。
我認為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上的缺省應用程序平臺，JavaAPIs也成為Internet應用程序開發的天然平臺。
Stroustrup：微軟和Sun把大筆的金錢扔在Java、VB和C#中，并不是因為他良心發現，也不是因為他們真的相信這些語言能夠帶給程序員更美好的生活，而是利益使然。
有一個說法，認為軟件工具廠商如果能夠把應用程序開發者的專業技術任務負擔起來，將獲取巨大的經濟利益。我對其背后的經濟分析頗為懷疑，我認為這很難成為現實，特別是當應用程序開發者使用開放的、標準化的工具時，他們可以有多種選擇，從而使上面的想法更加不可能。
多年以前，C++就已經具有泛型能力（也就是templates和STL），有運算符重載，有枚舉類型？我們會不會在Java的未來版本中看到這些特性？Java是不是應該納入這些特性呢？
Strousturp：從1988-89年起，C++就已經有了templates。但是我們花了不少時間來了解如何最好地運用這個工具，早期各廠家對于template的支持在品質上也有很大的差異。有些編譯器廠商動作遲緩，至少有一個主要的編譯器廠商（好像是指微軟，微軟在VisualC++4.0才開始支持template，在此之前一直聲稱template是過于復雜而又沒什么用的技術，時至今日，VisualC++對于template的支持在主流編譯器中都屬于最差的一檔——譯者注）暗中鼓勵聲名狼藉的反template宣傳，直到他們自己終于學會了這項技術為止。直到今天，對于template的支持在品質上仍然有待改進。
你上面提到的那些特性，我認為Java（還有C#）應該，也肯定會逐漸引入。那些對于程序員來說最有用的語言特性和概念，將會逐漸集中，成為各家主流語言的必然之選。也就是說，我認為類似析構函數和模板特殊化之類的機制，遠遠比枚舉等機制重要得多。
Lindholm：Java技術成功的原因之一，就是很清楚哪些不該做。我們得多問幾個為什么：這項特性是不是必不可少？增加它會帶來哪些開銷？運算符重載是C++中一項極其強大的特性，但是它也大大增加了C++語言的復雜度，很多人都難以招架。Java在各種可能的權衡之中，做出了明智的抉擇，找到了能力與需求之間的完美平衡點。
當然，Java也會發展，而且最重要的是，現在是開發者們在推動發展。Java增加泛型能力這件事，很好地展示了Java是如何通過整個開發者社群的參與，在權衡中決定正確的平衡點。關于增加泛型類型（generictypes）的“Java規格申請”（JavaSpecificationRequest，JSR）已經進入JCP（JavaCommunityProcess）程序，而且已經開發了很長一段時間（參見http：//java.sun.com/aboutJava/communityprocess/之JSR-014）?，F在，在JCP中，有超過80個JSRs正在討論中，這充分體現了整個體系對開發者的積極反饋和高度合作，這正是驅動Java平臺不斷進化的動力。
發展vs.革新（Evolutionvs.Revolution）
C++是一種發展型的語言，Java和C#似乎更像是革新型語言（它們是從頭設計的）？什么時候，革新型的語言才是必需的呢？
Lindholm：Java技術并非憑空出世，反而更像是發展型的。Java所有的特性，在Java平臺推出之前，都至少已經存在于另一種環境之中。Java的貢獻在于，在眾多的特性和權衡中，做出了合理的選擇，使得產品既實用，又優雅。Java技術對于程序員的態度是：撫養，但不溺愛。
Stroustrup：從技術上講，我并不認為Java和C#是什么“從頭設計的”革新型語言。倘若Java是從技術原則出發，從頭設計，大概就不會模仿C/C++那種丑陋和病態的語法了（不必驚訝，Stroustrup在很多場合表示過，C++采用C的語法形式，實在是迫于兼容性。他本人更偏愛Simula的語法——譯者）。
我認為，只有當程序員們面對的問題發生了根本的變化的時候，或者當我們發現了全新的、極其優越的程序設計技術，又完全不能為現存語言所支持的時候，我們才需要全新的語言。問題是，我們恐怕永遠也碰不到那些“根本”、“全新”的情況。
我以為，自從OOP問世以來，可稱為“根本”的新型程序設計技術，唯有泛型程序設計（genericprogramming）和生成式程序設計（generativeprogramming）技術，這兩項技術主要是源于C++templates技術的運用，也有一部分曾經被視為面向對象和函數式語言（functionallanguages）的次要成分，現在都變成正式、可用和可承受的技術了。我對于目前C++模板（template）程序設計的成果非常興奮。例如，像POOMA，Blitz++和MTL等程序庫，在很多地方改變了數值計算的方式。
Java和C#的一個“賣點”，就是它們的簡單性?，F在Java是不是快失去這個賣點了？
Stroustrup：新語言總是宣稱自己如何如何簡單，對老語言的復雜性頗多非議。其實這種所謂的“簡單性”，簡單地說，就是不成熟性。語言的復雜性，是在解決現實世界中極為煩瑣和特殊的復雜問題的過程中逐漸增加的。一個語言只要活的時間夠長，總會有某些地方逐漸復雜起來，或者是語言本身，或者是程序庫和工具。C++和Java顯然都不例外，我看C#也一樣。如果一種語言能夠度過自己的幼年時代，它會發現，自己無論是體積還是復雜性都大大增加了。
Lindholm：Java技術的的功能在增加，需要學習的東西也在增加。不過功能的增加并不一定帶來復雜性的增加。Java技術的發展，并沒有使學習曲線更加陡峭，只是讓它繼續向右方延展了。
標準
標準化語言和開放型語言各自的優點和缺點何在？
Lindholm：對于一個開放、不允許專有擴展、具有權威的強制性標準語言或者運行環境來說，不存在什么缺點。允許專有擴展就意味著允許廠商下套子綁架客戶。特別重要的是，必須讓整個平臺，而不只是其中一部分完全標準化，才能杜絕廠商們利用高層次的專有API下套子?？蛻粢笥羞x擇廠商的自由，他們既要有創造性，又需要兼容性。
Stroustrup：對于一個語言，如C/C++來說，建立正式標準（如ISO標準）最大的好處，在于可以防止某一個廠商操縱這種語言，把它當成自己的搖錢樹。多個廠商的競爭給用戶帶來的是較低的價位和較好的穩定性。
專有語言的好處，一是流行，二是便宜（不過等你被套牢了之后，情況就會起變化），三是對于商業性需求可以做出快速的反應。
標準化語言的特點之一是，它不能忽略特殊用戶的需求。比如我在AT&T中所考慮的東西，其規模、可靠性和效率要求，跟那些普通廠商關注的大眾軟件相比，根本不可同日而語。那些公司很自然只關注主要的需求。
然而，多數大機構和身處前沿的公司，都有著特殊的需求。C++的設計是開放、靈活和高效的，能夠滿足我所能想象的任何需求。跟其他的現代語言相比，C++的家長式作風可謂少之又少，原因就在這。當然，不能贊賞這一點的人會詬病C++的“危險”。
擁有正式和開放標準的語言主要是為編程工具的使用者和客戶服務的，而擁有專屬“標準”的語言，主要是為廠商服務的。
到這，關于面向對象編程的一些知識，就給大家介紹完了。希望對你有幫助。