OOA/OOD/OOP 轉載

OOA/OOD/OOP  

 

                                                  OOA

　　Object-Oriented Analysis：面向對象分析方法

　　是在一個系統的開發過程當中進行了系統業務調查之後，按照面向對象的思想來分析問題。OOA與結構化分析有較大的區別。OOA所強調的是在系統調查資料的基礎上，針對OO方法所須要的素材進行的歸類分析和整理，而不是對管理業務現狀和方法的分析。

　 　OOA（面向對象的分析）模型由5個層次（主題層、對象類層、結構層、屬性層和服務層）和5個活動（標識對象類、標識結構、定義主題、定義屬性和定義服 務）組成。在這種方法中定義了兩種對象類之間的結構，一種稱爲分類結構，一種稱爲組裝結構。分類結構就是所謂的通常與特殊的關係。組裝結構則反映了對象之 間的總體與部分的關係。

　　OOA在定義屬性的同時，要識別實例鏈接。實例鏈接是一個實例與另外一個實例的映射關係。

　　OOA在定義服務的同時要識別消息鏈接。當一個對象須要向另外一對象發送消息時，它們之間就存在消息鏈接。

　　OOA 中的5個層次和5個活動繼續貫穿在OOD（畫向對象的設計）過程當中。OOD模型由4個部分組成。它們分別是設計問題域部分、設計人機交互部分、設計任務管理部分和設計數據管理部分。

　　1、OOA的主要原則。

　　（1）抽象：從許多事物中捨棄個別的、非本質的特徵，抽取共同的、本質性的特徵，就叫做抽象。抽象是造成概念的必須手段。

　　抽象原則有兩方面的意義：第一，儘管問題域中的事物是很複雜的，可是分析員並不須要瞭解和描述它們的一切，只須要分析研究其中與系統目標有關的事物及其本質性特徵。第二，經過捨棄個體事物在細節上的差別，抽取其共同特徵而獲得一批事物的抽象概念。

　　抽象是面向對象方法中使用最爲普遍的原則。抽象原則包括過程抽象和數據抽象兩個方面。

　　過程抽象是指，任何一個完成肯定功能的操做序列，其使用者均可以把它看做一個單一的實體，儘管實際上它多是由一系列更低級的操做完成的。

　　數據抽象是根據施加於數據之上的操做來定義數據類型，並限定數據的值只能由這些操做來修改和觀察。數據抽象是OOA的核心原則。它強調把數據（屬性）和操做（服務）結合爲一個不可分的系統單位（即對象），對象的外部只須要知道它作什麼，而沒必要知道它如何作。

　　（2）封裝就是把對象的屬性和服務結合爲一個不可分的系統單位，並儘量隱蔽對象的內部細節。

　　（3）繼承：特殊類的對象擁有的其通常類的所有屬性與服務，稱做特殊類對通常類的繼承。

　 　在OOA中運用繼承原則，就是在每一個由通常類和特殊類造成的通常—特殊結構中，把通常類的對象實例和全部特殊類的對象實例都共同具備的屬性和服務，一次 性地在通常類中進行顯式的定義。在特殊類中再也不重複地定義通常類中已定義的東西，可是在語義上，特殊類卻自動地、隱含地擁有它的通常類（以及全部更上層的 通常類）中定義的所有屬性和服務。繼承原則的好處是：使系統模型比較簡練也比較清晰。

　　（4）分類：就是把具備相同屬性和服務的對象劃分爲一類，用類做爲這些對象的抽象描述。分類原則其實是抽象原則運用於對象描述時的一種表現形式。

　　（5）聚合：又稱組裝，其原則是：把一個複雜的事物當作若干比較簡單的事物的組裝體，從而簡化對復瑣事物的描述。

　　（6）關聯：是人類思考問題時常常運用的思想方法：經過一個事物聯想到另外的事物。能令人發生聯想的緣由是事物之間確實存在着某些聯繫。

　　（7）消息通訊：這一原則要求對象之間只能經過消息進行通訊，而不容許在對象以外直接地存取對象內部的屬性。經過消息進行通訊是因爲封裝原則而引發的。在OOA中要求用消息鏈接表示出對象之間的動態聯繫。

　　（8）粒度控制：通常來說，人在面對一個複雜的問題域時，不可能在同一時刻既能縱觀全局，又能洞察秋毫。所以須要控制本身的視野：考慮全局時，注意其大的組成部分，暫時不詳察每一部分的具體的細節；考慮某部分的細節時則暫時撇開其他的部分。這就是粒度控制原則。

　　（9）行爲分析：現實世界中事物的行爲是複雜的。由大量的事物所構成的問題域中各類行爲每每相互依賴、相互交織。

　　2、面向對象分析產生三種分析模型

　　一、對象模型:對用例模型進行分析,把系統分解成互相協做的分析類,經過類圖/對象圖描述對象/對象的屬性/對象間的關係,是系統的靜態模型

　　二、動態模型:描述系統的動態行爲,經過時序圖/協做圖描述對象的交互,以揭示對象間如何協做來完成每一個具體的用例,單個對象的狀態變化/動態行爲能夠經過狀態圖來表達

　　三、功能模型(即用例模型à做爲輸入)。

　　3、OOA的主要優勢

　　（1）增強了對問題域和系統責任的理解；

　　（2）改進與分析有關的各種人員之間的交流；

　　（3）對需求的變化具備較強的適應性；

　　（4）支持軟件複用。

　　（5）貫穿軟件生命週期全過程的一致性。

　　（6）實用性；

　　（7）有利於用戶參與。

　   4、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是一種抽象的範式。抽象能夠分紅不少層次，從很是歸納的到很是特殊的都有，而 對象可能處於任何一個抽象層次上。另外，彼此不一樣但又互有關聯的對象能夠共同構成抽象：只要這些對象之間有類似性，就能夠把它們當成同一類的對象來處理。

　　1、OOD背景知識

　　計算機硬件技術卻在飛速發展。從幾十年前神祕的龐然大物，到如今隨身攜帶的移動芯片；從每秒數千次運算到每秒上百億次運算。當軟件開發者們還在尋找能讓軟件開發生產力提升一個數量級的「銀彈」[Brooks, 95]時，硬件開發的生產力早已提高了百倍千倍。

　　硬件工程師們可以如此高效，是由於他們都很懶惰。他們永遠恪守「不要去從新發明輪子」的古訓。Grady Booch把這些黑箱稱爲類屬（class category），如今咱們則一般把它們稱爲「組件（component）」。

　 　類屬是由被稱爲類（class）的實體組成的，類與類之間經過關聯（relationship）結合在一塊兒。一個類能夠把大量的細節隱藏起來，只露出一 個簡單的接口，這正好符合人們喜歡抽象的心理。因此，這是一個很是偉大的概念，由於它給咱們提供了封裝和複用的基礎，讓咱們能夠從問題的角度來看問題，而 不是從機器的角度來看問題。

　　軟件的複用最初是從函數庫和類庫開始的，這兩種 複用形式實際上都是白箱複用。到90年代，開始有人開發並出售真正的黑箱軟件模塊：框架（framework）和控件（control）。框架和控件每每 還受平臺和語言的限制，如今軟件技術的新潮流是用SOAP做爲傳輸介質的Web Service，它能夠使軟件模塊脫離平臺和語言的束縛，實現更高程度的複用。可是想想，其實Web Service也是面向對象，只不過是把類與類之間的關聯用XML來描述而已[Li, 02]。

　　在過去的十多年裏，面向對象技術對軟件行業起到了極大的推進做用。在能夠預測的未來，它仍將是軟件設計的主要技術——至少我看不到有什麼技術能夠取代它的。

　　2、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也同樣。

　　3、OOD和傳統方法有什麼區別？

　　還記得結構化設計方法嗎？程序被劃分紅許多個模塊，這些模塊被組織成一個樹型結構。這棵樹的根就是主模塊，葉子就是工具模塊和最低級的功能模塊。同時，這棵樹也表示調用結構：每一個模塊都調用本身的直接下級模塊，並被本身的直接上級模塊調用。

　 　那麼，哪一個模塊負責收集應用程序最重要的那些策略？固然是最頂端的那些。在底下的那些模塊只管實現最小的細節，最頂端的模塊關心規模最大的問題。因此， 在這個體系結構中越靠上，概念的抽象層次就越高，也越接近問題領域；體系結構中位置越低，概念就越接近細節，與問題領域的關係就越少，而與解決方案領域的 關係就越多。

　　可是，因爲上方的模塊須要調用下方的模塊，因此這些上方的模塊 就依賴於下方的細節。換句話說，與問題領域相關的抽象要依賴於與問題領域無關的細節！這也就是說，當實現細節發生變化時，抽象也會受到影響。並且，若是我 們想複用某一個抽象的話，就必須把它依賴的細節都一塊兒拖過去。

　　而在OOD中，咱們但願倒轉這種依賴關係：咱們建立的抽象不依賴於任何細節，而細節則高度依賴於上面的抽象。這種依賴關係的倒轉正是OOD和傳統技術之間根本的差別，也正是OOD思想的精華所在。

　　4、OOD步驟

　　細化重組類

　　細化和實現類間關係,明確其可見性

　　增長屬性,指定屬性的類型與可見性

　　分配職責,定義執行每一個職責的方法

　　對消息驅動的系統,明確消息傳遞方式

　　利用設計模式進行局部設計

　　畫出詳細的類圖與時序圖

　　5、OOD設計過程當中要展開的主要幾項工做

　　（一）對象定義規格的求精過程

　　對於OOA所抽象出來的對象-＆-類以及聚集的分析文檔，OOD須要有一個根據設計要求整理和求精的過程，使之更能符合OOP的須要。這個整理和求精過程主要有兩個方面：一是要根據面向對象的概念

　　模型整理分析所肯定的對象結構、屬性、方法等內容，改正錯誤的內容，刪去沒必要要和重複的內容等。二是進行分類整理，以便於下一步數據庫設計和程序處理模塊設計的須要。整理的方法主要是進行歸

　　類，對類一＆一對象、屬性、方法和結構、主題進行歸類。

　　（二）數據模型和數據庫設計

　　數據模型的設計須要肯定類-＆-對象屬性的內容、消息鏈接的方式、系統訪問、數據模型的方法等。最後每一個對象實例的數據都必須落實到面向對象的庫結構模型中。

　　（三）優化

　　OOD的優化設計過程是從另外一個角度對分析結果和處理業務過程的整理概括，優化包括對象和結構的優化、抽象、集成。

　　對象和結構的模塊化表示OOD提供了一種範式，這種範式支持對類和結構的模塊化。這種模塊符合通常模塊化所要求的全部特色，如信息隱蔽性好，內部聚合度強和模塊之間耦合度弱等。

　　集成化使得單個構件有機地結合在一塊兒，相互支持。

　　6、OO方法的特色和麪臨的問題

　　OO方法以對象爲基礎，利用特定的軟件工具直接完成從對象客體的描述到軟件結構之間的轉換。這是OO方法最主要的特色和成就。OO方法的應用解決了傳統結構化開發方法中客觀世界描述工具與軟

　　件結構的不一致性問題，縮短了開發週期，解決了從分析和設計到軟件模塊結構之間屢次轉換映射的繁雜過程，是一種頗有發展前途的系統開發方法。

　 　可是同原型方法同樣,OO方法須要必定的軟件基礎支持才能夠應用，另外在大型的MIS開發中若是不經自頂向下的總體劃分，而是一開始就自底向上的採用 OO 方法開發系統，一樣也會形成系統結構不合理、各部分關係失調等問題。因此OO方法和結構化方法目前還是兩種在系統開發領域相互依存的、不可替代的方法。

　　7、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#？

6、發展 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++的「危險」。

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