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)

　　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++的“危險”。

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

http://blog.163.com/[email protected]/blog/static/5265959620100892220498/

 

OOA/OOD/OOP(轉)