《UML面向對象設計基礎》—第2章2.4節面向對象的益處

本節書摘來自異步社群《uml面向對象設計基礎》一書中的第2章2.4節面向對象的益處，作者【美】meliir page-jones，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

2.4　面向對象的益處

uml面向對象設計基礎

本節的題目既迎合憤世嫉俗者又符合盲從者。

一些反對者可能會說面向對象沒有什麼優點；它僅是一種流派或是一場從西方一些地區引發起的全球性陰謀。而一些激進派則宣稱面向對象是一流的并且是所有軟體成功的唯一途徑。面向對象不僅适用于windows系統，而且還适用于無所不能的分布式web體系結構。

這兩種說法都太極端。作者認為面向對象是有用的，但不能神化，它還不夠完美，其特定實用程式依賴于在軟體開發過程中的使用方法。

沒有一種有價值的軟體工程方法可以成為“當年時尚（fad of the year）”。當年時尚指某種方法在幾個月或一年内變得十分風行（有關“fad of the year”的詳細資訊參見[page-jones,1991]）。盲從者歇斯底裡地指望“當年時尚”可以解決所有的軟體問題。懷疑論者則給盲從者潑冷水而坐等其觀。當不加選擇地使用這種方法而效果平平後，盲從者則放棄這種方法蜂擁地轉向下一個當年時尚。如果你的企業在“技術的浪尖上搖擺”，則應馬上扭轉盲從的局面，可能會從面向對象的技術中獲得一些收益。

面向對象不是萬能的解決方案，愚蠢的解決問題方案也會使你的企業步入困境。然而正如在本書中将要看到，面向對象盡管充滿挑戰，但确實是一種有效的軟體開發方法。一個成熟而職業化的企業不應該以極端的方式對待面向對象，而應該認真研究面向對象方法并将面向對象納入開發專業軟體的長期計劃中。

下面讨論面向對象對企業的六個主要軟體活動的内在影響。

2.4.1　使用者需求分析

結構化技術的過程分析和資料分析之間的邊界在哪兒從未解決。資料流圖的過程世界與實體關系圖的資料世界難以共存。過程和資料分析在某些場合可以滿足要求，而在某些場合就會發生沖突。這種沖突在實時系統模型中尤為突出，如控制過程與資料模型的對應關系經常變得不清晰。

面向對象方法在生命周期的早期就将過程和資料研究融合在一起。盡管不能明确地稱為“過程和資料分析”，但在談論面向對象（如第1章所述）時稱“動态和靜态分析”更為妥當，使用面向對象概念将這兩方面的分析很好地協調起來。難怪有人将面向對象中過程和資料的融合比作einstein的相對論中空間和時間的融合，盡管這種比喻有些過分。

2.4.2　軟體設計

在軟體設計中，面向對象既有優勢，又有不足。

面向對象的優勢是使設計者将軟體中的棘手問題利用封裝特性隐藏起來，這些問題包括：費解的資料結構、複雜的組合邏輯、詳細的過程和資料之間的關系、高深的算法及可怕的裝置驅動程式。

面向對象的缺點是應用封裝和繼承特性使結構本身變得複雜。在面向對象中很難建立一個戈爾地雅斯吊床難結，要麼不可建立，要麼使得系統的運作像一匹負重的賽馬。避免出現這些問題正是面向對象設計者所面臨的挑戰。

本書旨在提供一些思想、技術和原則使讀者可以應付面向對象的設計挑戰。本書第二部分介紹 uml的大多數有用特性，uml是描述和探索設計問題的最流行方法。

第三部分介紹一些設計原則和準則，據此您可對設計進行評估。使用這些原則和準則可以建立面向對象的架構，由此可構造協調一緻的系統并可獨立進行維護。盡管面向對象的設計有時是非常艱辛的，但一旦完成它，對處理大量複雜單元所帶來的益處要多于采用其他設計技術。

2.4.3　軟體構造

采用面向對象方法建立系統最常考慮的品質要素為： 可重用性、可靠性、健壯性、可擴充性、分布性和可存儲性。

（1）可重用性

面向對象通過在類的級别上而不是在各子程式級别上提高代碼重用來改進軟體可重用性。在企業中通過開發和建立适合企業應用的類庫，這種方式實際上是建立一種新的符合特定需求的非常高層的語言。

在實際中，對象類是一個足夠複雜的有機體，可以作為獨立的軟體單元從公司中的一個應用移植到另一個應用。至少類可以利用輔助類的架構來完成其特定功能（在9.1和9.2節将進一步解釋）。

（2）可靠性

可靠代碼的運作具有可重複性和一緻性。僅當能用某種方法證明代碼的正确性時，代碼才可達到這些品質要求。面向對象代碼采用類的不變式（class invariants）确信的斷言，借助自身進行驗證。類的不變式是指給定類中的每一個對象必須滿足的條件。例如，類person的不變式可能為 dateofbirth <= todaysdate。

類的不變式（第10章介紹其他有關内容）使得徹底地驗證代碼成為可能。在靜态分析或檢查中，可以驗證設計或其結果代碼是否滿足設想的不變式條件。雖然不可能證明（即使采用面向對象）代碼絕對正确，但面向對象确實使檢查代碼的行為變得更加容易。

（3）健壯性

軟體的健壯性是指軟體發生故障時的完全恢複能力。典型故障為聲明錯誤、記憶體錯誤、外部裝置錯誤及算法溢出。健壯的軟體可以捕獲異常并執行故障恢複程式（通常稱為異常處理程式或營救程式）。

許多現代的面向對象語言和環境都支援錯誤檢測和處理功能，是以有利于開發健壯的軟體。獲得健壯的面向對象代碼的有效方法是将推斷和恒定條件的概念與異常處理的概念相結合。在某些面向對象環境中，在運作時可以監控恒定類和其他推斷，當推斷發生錯誤時，軟體可以輕松地恢複。

對異常處理的另一種方法就是不進行異常處理：不檢測異常，當異常發生時，隻是簡單地讓軟體崩潰。當然，也無健壯性可言！

（4）可擴充性

軟體的可擴充性簡單地用技術術語描述即“說明域與實作域之間是同構的”。用通俗的話說，即解決問題的模型應該滿足問題的模型。為此，必須保證使用者的一些小的改變不會導緻主要系統災難性的後果。并且，當修改面向對象代碼時，很少會引發其他部分産生的莫名其妙的問題。由于面向對象基于更高層次上建立軟體單元，它更接近生活的抽象，是以比傳統技術更容易建立“同構”。

可擴充性和繼承性經常一起使用。使用者常在已經聲明的主題中增加變量對系統進行擴充。例如：“不僅僅隻定義客戶，現在需要區分國内客戶和國外客戶”。使用面向對象技術，可以在已有的超類下增加繼承子類的方法實作擴充。

（5）分布性

1989年，面向對象管理組織（object-management group,omg）承擔了一個十分艱巨的任務：将幾十個主要硬體和軟體廠商統一在面向對象的可互操作标準上。我曾對他們所做的努力表示懷疑，但他們取得的成功使我感到震驚！

最為顯著的成果就是公共對象請求代理體系結構（common object request broker architecture, corba），這種軟體體系結構支援分布在多個平台上的面向對象系統（想了解有關corba的更多知識，參見[mowbray and zahavi，1995]和 [orfali et al.,1996]）。這種體系結構引起了人們的很大關注。corba還可使對象“互相交談”，不僅可以在類似的機器上，而且可以在運作不同作業系統或連接配接不同網絡的機器上進行通信。　

在corba環境中，甚至可以用不同的語言編寫類，然後用不同的編譯程式編譯的方式建立對象。此外，最重要的是corba提供了各種标準服務（如複制、代理、關系處理和事件仲裁等服務），這樣省去了編寫許多分布式系統必需的冗長代碼。

換言之，corba使平台的分布式和異構對使用者及應用設計者和程式設計者透明。編寫消息時可采用類似通常的單處理器的方式，讓 corba服務處理許多繁雜的底層細節。

（6）可存儲性

如果不提及面向對象資料庫管理系統，那麼本節就不能算完整。建立任何面向對象應用，odbms都非常有用，特别是應用涉及到聲音和圖像時更是如此，因為這些資料不适合用标準的表格形式存儲。

odbms可以存儲任意的對象類（不僅包括諸如string、real、integer和date類，而且還包括customer、aircraft 、citymap、videoclip等），此外，它還提供面向對象封裝、繼承、多态及其他重要的面向對象特性。大多數 odbms提供查詢語言（如面向對象查詢語言，oql）來代替關系dbms的sql。

2.4.4　軟體維護

可重用性、可靠性、健壯性、可擴充性是軟體維護的四大支柱。許多企業在軟體維護上花費很高。由于面向對象可以提高這四方面品質特性，是以能在以下方面降低系統的維護開銷：

可重用性降低了企業整個代碼維護的費用。減少了編寫新代碼及以後系統維護的量，特别是開發頭一兩個項目後，效果特别明顯。

可靠性減少了使用者的不滿意和對修正問題的痛苦抱怨。

健壯性確定軟體可被維護而不至于在桌面上癱瘓。

可擴充性迎合了使用者修改系統的“漸進式”傾向，是以，使用者可以不斷地對軟體尋求更多的較小的修改。

2.4.5　軟體使用

圖形應用一直是面向對象的主要選擇。通常人們通過面向對象實作圖形使用者界面（gui）。這樣做有兩個原因：其一是概念；其二是實作。

在概念上，面向對象的隐喻較好地符合典型的視窗/滑鼠/圖示界面。比如螢幕上有一個圖示，該圖示可以表示一個對象如客戶。用滑鼠點選圖示選擇該客戶，彈出一個菜單，菜單選項與應用于該客戶的方法一緻。如有一個選項對應changeaddress，而另一個選項對應reassesscreditlimit等。而且，國内客戶的菜單可以與國外客戶的菜單不同。每個菜單隻列出特定客戶類型的商業行為。

甚至多态性也可以出現在使用者界面中，多态性指一個方法對于不同的類可以有不同的含義和不同的實作。如螢幕上有一個圖示表示電子表格對象，而另一個圖示表示文檔對象。當使用者輕按兩下open菜單項時，可以根據這兩個圖示哪個被加亮，對該對象執行電子表格程式或文本處理程式。換言之，open方法的特定版本的執行依賴于被加亮的類是spreadsheet還是document。

在實作上，允許使用者可以建立視窗/滑鼠/圖示界面的許多商用軟體庫都是用面向對象語言編寫的。由于視窗本身具有許多面向對象的屬性，是以大多數視窗界面的開發工具，都有通過視窗運作面向對象的痕迹。

是以，如果說面向對象本身增加了軟體的易用性不太準确，但可以準确地說，好的圖形使用者界面增加了軟體的易用性，而面向對象是建立支援gui軟體庫的最佳途徑。

2.4.6　軟體項目管理

目前為止，本書涉及的大部分内容是面向技術人員的。但針對經理的内容是什麼？面向對象的另一個技術特色是否一定會慢慢消亡或轉到另一個企業？或者面向對象僅僅是使經理搬起石頭砸自己腳的絆腳石？

回答是否定的。面向對象不僅适合普通人員，也适合經理們。例如，降低維護開銷的技術可以釋放管理者的資源，将其投入到待處理的應用中。在經理們看來，面向對象不是純技術的，面向對象既能給企業的組織也能給經理的工作帶來變化。

當一個企業采納了面向對象，其組織将發生變化。 類的重用需要類庫和類庫管理人員。 每個程式員都要加入到兩個組中的一個：一個是設計和編寫新類組，另一個是應用類建立新應用程式組。面向對象不太強調程式設計（重用性意味減少新代碼），需求分析相對地将變得更加重要。

新的符号語言如uml也将帶來重大影響。盡管需求分析和軟體設計是不同的兩個方面，但uml被廣泛地應用到這兩個模型中。這使現代的o.o.符号化，而結構技術在這方面是非常缺乏的。直到我遇到一家新的面向對象企業的經理告訴我下面一段話，我才意識到這兩方面是密不可分的：

過去，技術人員在畫圓形圖（資料流圖中的過程）時，知道他們在做分析，轉到畫方框圖（結構圖中的子產品）時，知道他們開始設計。現在我從不知道他們在做什麼并對此十分擔心！

作為轉向面向對象企業的經理，應該意識到組織的變化。讓職員适應新的角色，在這些角色中需要管理參與工作的人員，鼓勵重用而不主張重複編碼。需要給技術人員充足的時間考慮類的設計使得構造的類可以滿足重用的要求。總之，應該使用不同的術語、不同的工具和不同生命周期以及新的目标來管理項目。

如果經理将面向對象作為一種方法而不是作為一種目标，将會取得良好的效果。面向對象是有可維護性、可擴充性、健壯性、分布性、gui支援，減少傳遞時間等諸多益處。作為經理應始終确立目标，并将面向對象作為一種技術來達到預定的目标。

如果在頭腦中沒有目标，那麼面向對象的所有事物開銷（金融、組織、社會及感情）似乎都是昂貴的代價。然而，如果不僅知道做什麼，而且知道為什麼這樣做，你就能實作你所追求的面向對象目标。

本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。