周立功教授數年之心血之作《程序設計與數據結構》以及《面向AMetal框架與接口的編程（上）》，電子版已無償性分享到電子工程師與高校群體，書本內容公開后，在電子行業掀起一片學習熱潮。經周立功教授授權，本公眾號特對《程序設計與數據結構》一書內容進行連載，愿共勉之。

第四章為面向對象編程，本文為4.3 繼承與多態。

>>> 4.3.1 抽象

假設需要設計一個處理工資單的數據包，可以將排序作為一個關鍵的業務進行抽象。雖然各種排序的實現不一樣，但它們的共性都是“排序”，這就是抽象的基礎。如果要建立一個矩陣代數程序包，就要討論抽象矩陣。雖然各種類型矩陣的實現各不相同，但根據它們表現的共同行為特性，可以將這些矩陣歸為一類，顯然其共性又一次支持了抽象。

如果用戶有一個這樣的需求——校驗push到棧中的數據，則實現者一定會問“校驗規則是什么？”因為校驗是一個非常“抽象”的概念；如果用戶明確地告訴實現者——對push到棧中的數據進行范圍值校驗或偶校驗，則不會出現這樣模糊的問題。當需要對push到棧中的數據進行范圍值校驗時，則需要編寫一個RangeValidator類；當再需要添加一個奇偶校驗器時，勢必又要編寫一個OddEvenValidator類。顯然每添加一種校驗器就要增加一個接口，根本無法做到重用。

雖然它們的類型不同，且不同校驗器的對象各有不同，但它們共同的概念都是“校驗器”。回歸校驗器的本質，無論是什么校驗器，其共同的屬性是校驗參數，其共同的行為是可以使用相同的方法——在動態中根據對象的類型調用不同的校驗器函數。

顯然，用戶是在概念層次上提出了校驗的需求與實現者交流，而具體如何校驗是在實現層次進行的，用戶無需準確地知道具體是如何實現的。因此只要概念不變，即可做到用戶與實現細節的變化完全分離。

在面向過程編程中，新手對共性的認識往往來源于直覺，以創建范圍值校驗器類和偶校驗器類為例，程序員普遍都會按照以下方法表達這種共性，將Validate提取為一個公共的函數指針。比如：

而對于一個擁有“面向對象思維”且經驗豐富的程序員，更傾向于將各種校驗器的共性打包在一個函數指針中作為結構體的成員創建一個抽象類。Validator抽象類的定義如下：

其中，pThis是指向當前對象的指針，Validator是一個沒有具體屬性，代表多種具有共性的數據和行為的具體校驗器總稱的抽象類。Validator類沒有提供任何實現validate方法的代碼，正是因為這一點，該方法才能成為一個抽象的方法，因為提供任何代碼都會使方法成為具體方法。

由于Validator是一個抽象類，因此無法創建實例，自然也就不知道要校驗什么？那么誰知道呢？范圍值校驗器和奇偶校驗器類知道自己要做什么校驗。由于Validator有一個validate方法，因此可以將Validator抽象類封裝成RangeValidator派生類的成員——Validator類的變量isa，即將實現細節委托給子類。在范圍值校驗器和奇偶校驗器類重新定義，各自實現它自己的validate方法。

>>> 4.3.2 繼承

在這里將引入一個新的概念繼承描述類之間的關系。由于RangeValidator范圍值校驗器和OddEvenValidator奇偶校驗器的共性是校驗參數和調用校驗函數的方法，因此將其共性上移到一個名為Validator校驗器類（父類）中。

基于此，在將具有可變性的校驗參數分別轉移到RangeValidator和OddEvenValidator中的同時，并將Validator類型的變量isa作為結構體的成員，即可創建新的結構體數據類型：

其中，pThis為指向Validator類對象的指針，RangeValidator和OddEvenValidator派生自Validator類，RangeValidator和OddEvenValidator是Validator的子類，Validator類是RangeValidator和OddEvenValidatorr類的基類或超類。因為RangeValidator是一種校驗器，OddEvenvalidator也是一種校驗器。當一個子類繼承自一個基類時，它可以做基類能做的任何事情，因此RangeValidator和OddEvenValidator都是Validator的擴充。

雖然父類和子類的類型不一樣，當通過繼承將不同類的共同屬性和行為抽象為一個公共的基類后，于是它們就具有了共同的屬性和行為，這就是OOP通過繼承實現代碼重用的方法。因為抽象類在概念上定義了相似的一組類的共同屬性和方法，因而能夠將這一組相關類看成一個概念。也就是說，抽象類代表了將所有派生類聯系起來的核心概念，也正是這個核心概念定義了派生類的共性。同時還提供了與這一組相關類的通信接口規約，然后每個具體類都按需要提供特定的實現。

由此可見，對于一個新的抽象，必須將它放在已經設計好的類和對象層次結構的上下文中。實際上，這既不是自上而下的活動，也不是自下而上的活動。Halbert和O 'Brien指出，“當在一個類型層次結構中設計類時，并非總是從基類開始，然后創建子類。通常會創建一些看起來不相似的類型，當意識到它們是相關時，然后才將它們的共性分離出來，放到一個基類或多個基類中……”實踐經驗證明，類和對象的設計是一個增量、迭代的過程。Stroustrup認為，“最常見的類層次結構的組織方式是從兩個類中提取公共部分放到一個新類中，或將一個類拆分為兩個新類。” 比如，將RangeValidator和OddEvenValidator的共性上移到Validator中。

由于許多開發者常常忽略了為對象和類正確地命名，因此必須確保創建類、屬性和方法名時，不僅要遵循約定，還要讓名字具有描述性，讓人一目了然。否則解釋權在程序員自己，因為程序員的個性，時常有可能創建一些只對他們自己很有道理的約定，而其他人卻完全不能理解。類名不能為動詞，類名應該用常見的名詞命名，比如，Validator或RangeValidator，避免使用Manager、Processor、Data或Info這樣的類名。對象名應該用合適的名詞短語命名，比如，rangeValidator或oddEvenValidator。特別地，選擇的名字應該是業務領域專家使用和認知的名字。方法名應該是動詞或動詞短語，比如，pushWithValidate。

當開發者決定采用某種協作模式后，工作會被分解給對象，即在相應的類上定義適當的方法。歸根到底，單個類的協議包含了實現所有行為，以及實現與其實例相關的所有機制所需要的全部操作。因此與類層次結構的設計一樣，機制代表了戰略的設計決策。

實際上，機制就是在長期的實踐中發現和總結的各種模式。在底層開發模式中，慣用法是一種表現形式；在高層開發模式中，則有一組類組成的框架。框架代表了大規模的復用，比如，ZLG的AMetal框架和AWorks框架，MVC框架和MVVM框架以及微軟的.NET框架或開源代碼。所以機制代表了一種層次的復用，它高于單個類的復用。

雖然代碼表明了基類與子類的關系，但還是不夠深刻。在這里，將以Validator與RangeValidator之間的繼承關系為例，通過UML圖進一步形象地描述，詳見圖 4.4。

圖 4.4 繼承關系圖

繼承關系為何指向基類？其深刻的設計思想是它代表了依賴的方向。所謂依賴關系是指兩個元素之間的一種關系，其中一個元素變化將會引起另一個元素變化。UML圖中采用從子類指向基類的空心箭頭表示繼承，暗示基類的變化可能導致子類的變化。簡而言之，被依賴的先構造，依賴于其它元素的后構造。

其實繼承是一個非常傳統和經典的術語，從Smalltalk問世時就被廣泛使用，將一般類和它的特殊類之間的關系稱為繼承關系。它在很多場合還以動詞或形容詞的面目出現。比如，特殊類繼承了一般類的屬性和操作，面向對象編程語言具有繼承性和封裝性等。

而一般-特殊恰當地一般類和它的特殊類之間的相對關系，既可以稱為一般-特殊關系，也可以形成一般-特殊結構。當“一般”這個術語generalization翻譯成中文時，很容易與上下文混淆，因此翻譯成“泛化”更準確。即一般類（父類）對特殊類（子類）而言是泛化，反之就是特化。因此一般類和特殊類之間的關系稱為一般-特殊關系，一般-特殊結構是由一組具有一般-特殊關系（繼承關系）的類所形成的結構。

顯而易見，一般-特殊結構是問題域中各類事物之間客觀存在的一種結構，在面向對象分析模型中建立一般-特殊結構，使模型更清晰地映射了問題域中事物的分類關系——將對象劃分為類，用類描述屬于它的全部對象實例。它將具有一般-特殊關系的類組織在一起，可以簡化對復雜系統的認識，使人們對系統的認識和描述更接近日常思維中一般概念和特殊概念的處理方式。

在面向對象的開發中，一般-特殊結構可以使開發者簡化對類的定義，因而對象的共同特征只需在一般類中給出，特殊類通過繼承而自動地擁有這些特征，不必再重復定義。

不同的方法學對如何發現一般-特殊結構，有不同的策略。其最大的問題讓人們感到更多地是依賴于直覺，如果分析方法是一門藝術，也就意味著讓人具有很大的不確定性。而事實上，使用共性和差異化分析工具，并從概念、規約和實現三個不同的視角看待對象，就可以簡化復雜的系統，詳見《嵌入式軟件工程方法與實踐叢書——面向對象的分析與設計》。

>>> 4.3.3 職責驅動設計

OO強調的是在現實世界或業務領域中找出軟件對象，而軟件對象與現實世界中對象的行為完全不一樣。軟件對象以點對點的通信方式通過發送消息進行交互，而現實世界中的對象與環境的交互，以及其它對象動態地反映現實世界的對象之間交互都要豐富得多。

經驗豐富的開發人員在研究領域時，如果發現了他們所熟悉的某種職責或某個關系網，他們會想起以前這個問題是如何解決的。以前嘗試過哪些模型？在實現中有哪些難題？它們是如何解決的？先前經歷過的嘗試和失敗的教訓，會突然間與新的情況聯系起來。

為了真實地反映現實世界中對象的動態交互，要讓一個類在不同的系統中重用，則必須在設計類時充分考慮擴展性。經過長期的積累，人們總結了一套用于啟發和指導類的設計原則：職責驅動設計——如何為協作中的對象分配職責。

顯然，對于rangeValidator對象和oddEvenValidator對象來說，它們的職責分別是對push到棧中的數據進行范圍值校驗和偶校驗，也就意味著必須存在相應的方法。由于每個子類都要對自己的行為負責，因此每個子類不僅要提供一個名為validate的方法，而且必須提供它自己的實現代碼。比如，RangeValidator和OddEvenValidator都有一個validate的方法，RangeValidator類包含范圍值校驗的代碼，OddEvenValidator類肯定有奇偶校驗的代碼。它們都是Validator的子類，必須實現其不同版本的validate。

不言而喻，OOP比POP更直接地表達了校驗器的共性：“使用validate函數指針在運行中根據對象的類型調用不同的函數，并通過pThis指針指向當前對象引用校驗參數將共同的部分打包在一起形成抽象類。”當它們有了這種共性時，則更容易討論各種校驗器相互之間的差別。

除了變量value之外，RangeValidator類對象的validateRange()校驗函數的共性是符合范圍值條件的判斷處理語句，其可變的是范圍值校驗參數min和max；OddEvenValidator類對象的validateOddEven()校驗函數的共性是符合偶數值條件的判斷處理語句，其可變的是偶校驗參數isEven。

根據共性和可變性分析原理，將穩定不變的相同的處理部分都包含在抽象的模塊中，可變性分析所發現的變化的變量由外部傳遞進來的參數應對。其函數原型如下：

由于&rangeValidator.isa、&oddEvenValidator.isa和pThis值相等，且類型也相同，因此可以將范圍值校驗和奇偶校驗函數的void *泛化為Validator *。當將一個基類對象替換成它的子類對象時，程序將不會產生任何錯誤和異常，且使用者不必知道任何差異，反過來則不成立。也就是說，如果某段代碼使用了基類中的方法，必須能使用派生類的對象，且自己不必進行任何修改。因此在程序中要盡量使用基類類型定義對象，在運行時再確定其子類類型，用子類對象替換基類對象。這就是里氏替換原則，它是由2008年圖靈獎獲得者，美國第一位計算機科學女博士Barbara Liskov教授和卡耐基梅隆大學Jeannette Wing教授于1994年提出的。

在應用里氏替換原則時，應該將父類設計為抽象類或接口，讓子類繼承父類或實現父類接口，并實現在父類中聲明的方法。在運行時子類實例替換父類實例，可以很方便地擴展系統的功能。無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類實現，由此可見，里氏替換原則是實現開閉原則的重要方式之一。

如果開閉原則是面向對象設計的目標，那么依賴倒置原則就是面向對象設計的主要原則之一，它是抽象化的具體實現。依賴倒置原則要求傳遞傳遞參數時或在關聯關系中，盡量引用高層次的抽象層類，即使用接口和抽象類進行變量的聲明、參數類型的聲明、方法返回類型的聲明，以及數據類型的轉換等，而不要用具體類做這些事。

為了確保該原則的應用，一個具體類應該只實現接口或抽象類中聲明過的方法，而不是給出多余的方法，否則將無法調用在子類中增加新的方法。顯而易見，在引入抽象層后，將具體類寫在配置文件中。如果需求發生改變，則只需要擴展抽象層，修改相應的配置文件即可。而無須修改原有系統的代碼，就能擴展系統的功能，滿足開閉原則。通常開閉原則、里氏替換原則和依賴倒置原則會同時出現，開閉原則是目標，里氏替換原則是基礎，依賴倒置原則是手段，它們相輔相成相互補充，其目標是一致的，只是分析問題的角度不同。

繼承是OO建模和編程中被廣泛濫用的概念之一，如果違反了LisKov替換原則，繼承層次可能仍然可以提供代碼的可重用性，但是將會失去可擴展性。因此在使用繼承時，要想一想派生類是否可以替換基類。如果不能，則要問一問自己為何使用繼承？如果在編寫新的類時，還要重用基類代碼代碼，則要考慮使用組合。

和繼承一樣，組合也是一種構建對象的機制。如果新類可以替換已有的類，且它們之間的關系可以描述為is-a，則使用繼承。如果新類只是使用已有的類，且它們之間的關系可以描述為has-a，則使用組合。相對繼承來說，組合更加靈活，適用性也更強。

有關組合的使用方法和示例，將在后續相關的教程中，結合具體的應用予以闡述。

在這里，RangeValidator和OddEvenValidator類擴展了（即繼承）Validator，其相應的校驗器接口的實現詳見程序清單 4.9。

程序清單 4.9 通用校驗器接口的實現（Validator.c）

由此可見，抽象是一個強大的分析工具，其強調的什么是共同的，因此共性和差異化分析自然而然地成為了抽象的理論基礎。共性分析尋找的是不可能隨時間而改變的結構，而可變性分析則要找到可能變化的結構。如果變化是“業務領域”中各個特定的具體情況，那么共性就定義了業務領域中將這些情況聯系起來的概念。共同的概念用抽象類表示，可變性分析所發現的變化將通過從抽象類派生而來的具體類實現。共性與可變性分析工具不僅可以指導我們創建抽象類和派生類，而且還可以指導我們建立抽象和接口。那么類的設計過程自然而然地就簡化成了兩個步驟：

• 在定義抽象類（共性）時，需要知道用什么接口處理這個類的所有職責；

• 在定義派生類（可變性）時，需要知道對于一個給定的特定實現（即變化），應該如何根據給定的規約實現它。

顯然，類是一種編程語言結構，它描述了具有相同職責的所有對象。用相同的方式實現這些職責，并共享相同的數據結構。雖然它的內部可能有一些屬性，可能有一些方法，但我們只關心對象對自己的行為負責。因為將實現隱藏在接口之后，實際上是將對象的實現和使用它們的對象徹底解耦了。所以只要概念不變，請求者與實現細節的變化隔離開了。

為了便于閱讀，程序清單 4.10展示了通用校驗器的接口。

程序清單 4.10 通用校驗器的接口（validator.h）

在這里，還是以范圍值校驗器為例，假設min=0，max=9，如程序清單 4.10（22）所示的使用名為newRangeValidator的宏將結構體初始化的使用方法如下：

宏展開后如下：

其中，外面的{}為RangeValidator結構體賦值，內部的{}為RangeValidator結構體的成員變量isa賦值。即：

如果有以下定義：

即可用pValidator引用RangeValidator的min和max。

由于pValidator與&rangeValidator.isa不僅類型相同，而且它們的值相等，則以下關系同樣成立：

因此可以利用這一特性獲取validateRange()函數的地址，即pValidator->validate指向validateRange()。其調用形式如下：

此時此刻，也許你會想到，既然它們的方法都一樣，只是屬性不同，為何不將它們合并為一個類呢？如果這樣做的話，則一個類承擔的職責越多，它被復用的可能性就越小。而且一個類承擔的職責過多，就相當于將這些職責耦合在一起。當其中一個職責變化時，可能會影響其它職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同的變化原因封裝在不同的類中。如果多個職責總是同時發生變化的話，則可以將它們封裝在同一個類中。

也就是說，就一個類而言，應該只有一個引起它變化的原因，這就是單一職責原則，它是實現高內聚、低耦合的指導方針。這是最簡單也最難運用的原則，需要開發人員發現類的不同職責并將其分離。

>>> 4.3.4 多態性

多態性是面向對象程序設計的一個重要特征，多態（函數）的字面含義是具有多種形式。每個類中操作的規約都是相同的，而這些類可以用不同的方式實現這些同名的操作，從而使得擁有相同接口的對象可以在運行時相互替換。

當向一個對象發送一個消息時，這個對象必須有一個定義的方法對這個消息作出響應。在繼承層次結構中，所有子類都從其超類繼承接口。由于每個子類都是一個單獨的實體，它們可能需要對同一個消息作出不同的響應。比如，Validator類和行為validate。

在面向對象的編程中，真正引用的是從抽象類派生的類的具體實例。當通過抽象引用概念要求對象做什么時，將得到不同的行為，具體行為取決于派生對象的具體類型。因此，為了描述事物之間相同特性基礎上表現出來的可變性，于是多態就被創造出來了，多態允許用相同的方法（代碼）處理不同行為的對象。

多態是一種運行時基于對象的類型發生的綁定機制，通過這種機制實現函數名綁定到函數具體實現代碼的目的。當執行一個程序時，構成程序的各個函數分別在計算機的內存中擁有了一段存儲空間，一個函數在內存中的起始地址就是這個函數的入口地址，因此多態就是將函數名動態綁定到函數入口的運行時綁定機制。盡管多態與繼承緊密相關，但通常多態被單獨看作面向對象技術最強大的一個優點。

顯然，調用校驗器就是發送一個消息，它要使用validate函數指針。實際上無論范圍值校驗器還是奇偶校驗器，其校驗過程都是由不同內容的函數實現的。在面向對象的編程中，在不同的類中定義了其響應消息的方法，那么在使用這些類時，則不必考慮它們是什么類型，只要發布消息即可。正如在調用校驗器時，不必考慮其調用的它們是什么校驗器，直接使用validate函數指針，無論什么類型校驗器都能實現檢查功能。

由于RangValidator和OddEvenValidator類都繼承自Validator類，因此沒有必要在繼承樹中對每一種校驗器都重復定義這些屬性和行為，重復不僅需要做更多的事情，甚至還可能導致錯誤和出現不一致，詳見圖 4.5。這種關系在UML中表示為一條線，并有一個箭頭指向父類。這種記法非常簡明扼要，當遇到這種帶箭頭的線時，就知道存在一個繼承并呈現多態的關系。

圖 4.5 抽象類的層次結構

在設計Validator時，對各種校驗器的使用進行標準化會有很大的幫助，因為無論是何種校驗器，都用一個名為validate的方法。如果遵循這個規范，不管什么時候校驗數據，只需要調用validate方法即可。無需考慮這到底是什么校驗器，于是就有了一個真正多態的Validator框架——由各個對象自己負責完成校驗，不論它是范圍值校驗、奇偶校驗還是質數校驗。

根據開閉原則，需要再編寫一個擴展push功能的pushWithValidate()函數，其原型如下：

如果需要進行范圍值校驗，則pValidator指向rangeValidator，否則將pValidator置NULL。

pushWithValidate()的具體實現如下：

其調用形式如下：

使用通用校驗器的應用范例程序詳見程序清單 4.11。

程序清單 4.11 使用通用校驗器的范例程序

由此可見，雖然OOA和OOD的邊界是模糊的，但它們關注的重點不一樣。OOA關注的是分析面臨的問題域，從問題域詞匯表中發現類和對象，實現對現實世界的建模。OOD關注的是如何設計泛化的抽象和一些新的機制，規定對象的協作方式。

---