《C++面向對象高效程式設計（第2版）》——1.9 面向對象軟體開發的階段

本節書摘來自異步社群出版社《c++面向對象高效程式設計（第2版）》一書中的第1章，第1.1節，作者： 【美】kayshav dattatri，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

c++面向對象高效程式設計（第2版）

很顯然，軟體工程不是從研究一組類或對象開始的。我們從簡單描述問題開始（大多數都不完整），這是面向對象軟體開發過程的起點。在這一階段中，我們要找到合适的類。記住，為了提供良好的解決方案，大多數複雜的問題需要的不隻是一個類，而是許多類。一組類可以互相通信、合作和協作，以完成最終的目标。問題是我們如何找到（甚至創造）所需的類？這可能是面向對象軟體開發過程中最困難的一步，這一過程占據了相當長的時間。由于問題的說明不完整，或陳述的問題通常是面向實作而非面向問題，導緻很難找出能設計成類的部分。

面向對象分析（object-oriented analysis，縮寫ooa）涉及從類和對象的角度分析問題，這些類和對象都要從問題領域（problem domain）中找出。但是，這些類并不是在最終實作中能直接使用的類。整個過程基本上是一個模組化練習，即嘗試建立問題領域的模型。本階段的任務主要是，徹底地分析問題和明确地指定要求。要在客戶的問題領域找出類和對象，并用其完整地描述什麼方案可行，什麼方案不可行。換言之，我們應采用客戶能夠了解的類和對象來描述問題。這些類和對象都可以直接在問題領域中找到。

接下來要思考的是：問題領域這個術語是什麼意思？任何待解決的問題都與一個或多個（通常未知）領域相關，我們需要尋求熟悉這些領域的人提供專業知識和技術方面的幫助，才能提出解決方案。例如，為銀行管理事宜設計一個解決方案，需要尋求銀行管理人員的幫助。此時我們認為，這個問題屬于銀行（或金融）領域。簡而言之，問題領域就是問題所屬的區域或部門。問題領域（或簡稱領域）的範圍很廣，可以是浴室改建、自行車制造、機械設計、收款賬戶、庫存管理、fda審批、生物-實體仿真、網絡化、使用者接口、動畫、财政、辦公自動化、分布式計算、數值分析、計算機通信、資料庫管理等。一個人不可能精通所有的領域，是以在沒有其他人的幫助下，無法解決不同領域的問題。

即使是面向對象軟體開發的專家，要解決銀行管理的問題，也需要銀行管理人員的幫助。銀行管理人員非常清楚銀行系統的需求，也知道目前系統的缺點，是以他們能提供大量有用的資訊，是名副其實的領域專家。但是，通常這些專家對程式設計一無所知，不具備程式設計技能。

根據領域專家的介紹，熟悉面向對象軟體開發的人就能提出解決方案。如果沒有專家的幫助，不可能設計出優秀的面向對象（oo）方案。要解決任何與現實相關的問題，都需要領域專家和面向對象軟體專家的密切合作。

ooa階段的成果不可能完整。我們在該階段中（即在開始實作之前），進行了大量的工作，僅僅提出了一個解決方案的架構。但這是個很好的開端。注意，在ooa階段中，我們應該将注意力放在問題領域中使用的類，而非實作中使用的類。實作的細節将在面向對象設計（ood）階段實作。

通過以上ooa的分析可知，類與生俱來。在現實生活中，我們每天都遇到各種不同的類：郵局、郵箱、賬單、管理人員、鮮花、報紙、微波爐、cd唱機、父親、母親和汽車等。這些都是我們在日常生活中打交道的對象。我們很清楚這些對象可以做什麼，他們的目的是什麼。在軟體開發過程中，就涉及為問題領域中已知的對象模組化。我們可以将現實生活中了解的對象映射到問題解決方案的邏輯視圖中。例如，在一個公司管理的問題中，可以将公司的職員當做對象。類似地，再次使用類和對象，将公司的薪水模組化為薪水管理系統。由于我們已經很好地了解了所涉及的類和對象，是以在軟體解決方案中，通過對現實世界的仿真更容易解決問題。這也能幫助我們控制（和管理）問題的複雜程度。現實生活中對象有一定的局限性。例如，我們不能要求郵差向我的叔叔送花1，也不能要求微波爐播放cd。我們很清楚現實生活中這些對象的能力和局限，這些同樣也映射在我們的解決方案中。在一些情況下，這種映射很簡單（如在公司管理系統或者銀行賬戶管理系統中）。但是，在某些情況下，特别是在針對計算機軟體的問題中，我們通常無法确定對象，是以要找到這些對象相當不易。例如，很難為一個中斷管理系統找到一組類，因為這樣的類沒有任何對象。是以，在建立解決方案的架構之前，我們需要在ooa階段徹底地分析問題。由此可見，要解決涉及交易處理的問題絕非易事。

1.9.2 面向對象設計（ood）

ood（面向對象設計）階段在ooa（面向對象分析）階段之後，在本階段中，我們将在ooa階段開發的架構中加入細節，待解決的問題将被分解為類和對象用于實作中。本階段需要完成的任務包括定義類之間的關系、描述對象如何才能适應系統的程序模型、如何跨位址空間劃分對象、系統如何完成動态行為等。ood階段的成果将更加清楚，而且更容易了解。盡管如此，它仍然是不完整的。由于設計的實作尚未完成，是以我們對解決方案的真實行為還一無所知。

找到那些難以琢磨的對象

為實作一個解決方案，找到（實際上是創造和發現）一組正确的類并不簡單。事實上，這是最困難的事情。在這個過程中，你可能不得不使用所有的相關指導原則和被證明行之有效的方法（并透徹地了解問題），來生成一組初始的類。一般情況下，可将問題中的下列實體轉化為類：

人，位置和東西；

事件滑鼠輸入、出生、死亡等；

交易同意貸款、汽車銷售等；

人所扮演的角色父親、母親等。

對于較簡單的問題，設計人員通過将名詞作為類，将動詞作為這些類的方法，即可獲得關于類的線索。但是，在用語言描述此問題時，卻很容易将名詞和動詞的角色完全颠倒。是以，通過這種途徑獲得的類的線索，在探索過程中僅作參考。

ooa和ood都遵循一些現有的設計方法論。方法論（methodology）使用一些表示法來表示類、對象以及它們之間的關系。它支援系統不同模型（邏輯和實體）的描述，是設計過程中不可或缺的基本工具。表示法像是設計團隊都明白的一門共同語言，為設計團隊提供了共同的詞彙，友善交流。一些正在使用的流行方法論如下：

（1）booch方法論2。

（2）rumbaugh方法論3（也稱為omt-object模組化工具）。

（3）shlaer&mellor方法論4。

（（1）和（2）現在合并為統一模組化語言（unified modeling language），将在第2章中介紹）

注意，僅學習一種設計方法論并不能成為ood專家。方法論隻是一種用于表達設計思路的工具，它能讓其他人更好地了解使用者的想法和思路。方法論可以在設計過程中提供幫助，但是對發現類和實作類卻無能為力。設計小組成員的知識和經驗是無可取代的。

ooa和ood都不是c++語言所特有的5，它們是解決任何面向對象問題的基本方法。事實上，ooa和ood并不依賴于任何語言。不過，如果能預先知道在實作中将使用何種語言，會有所幫助。在設計階段，有可能出現這樣的情況：要使用多個類之間的特殊關系，但某些語言并不支援類間的這種關系。例如，設計中要用到的多重繼承，但smalltalk并不支援多重繼承。此時，如何用smalltalk來實作多重繼承成了大問題，解決這樣的問題需要程式員付出相當大的努力。是以，事先了解（如果有可能的話）實作中所使用的語言，對設計有很大幫助。另外，在設計環節中，不應該使用某種語言所特有的文法小細節。設計應盡可能獨立于語言的特定要素。令人欣慰的是，ooa和ood幾乎獨立于任何語言，可以在客戶標明的任何面向對象語言中實作設計的方案。