>>>1.1.1 抽象

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

如果用戶有一個這樣的需求——校驗push到棧中的數(shù)據(jù)，則實現(xiàn)者一定會問“校驗規(guī)則是什么？”因為校驗是一個非?！俺橄蟆钡母拍?；如果用戶明確地告訴實現(xiàn)者——對push到棧中的數(shù)據(jù)進行范圍值校驗或偶校驗，則不會出現(xiàn)這樣模糊的問題。當需要對push到棧中的數(shù)據(jù)進行范圍值校驗時，則需要編寫一個RangeValidator類；當再需要添加一個奇偶校驗器時，勢必又要編寫一個OddEvenValidator類。顯然每添加一種校驗器就要增加一個接口，根本無法做到重用。

雖然它們的類型不同，且不同校驗器的對象各有不同，但它們共同的概念都是“校驗器”?；貧w校驗器的本質(zhì)，無論是什么校驗器，其共同的屬性是校驗參數(shù)，其共同的行為是可以使用相同的方法——在動態(tài)中根據(jù)對象的類型調(diào)用不同的校驗器函數(shù)。

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

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

1 typedef bool(*const Validate)(void *pThis, int value);

2 typedef struct{

3 Validate validate;

4 const int min;

5 const int max;

6 }RangeValidator;

7

8 typedef struct{

9 Validate validate;

10 bool isEven;

11 }OddEvenValidator;

而對于一個擁有“面向?qū)ο笏季S”且經(jīng)驗豐富的程序員，更傾向于將各種校驗器的共性打包在一個函數(shù)指針中作為結(jié)構(gòu)體的成員創(chuàng)建一個抽象類。Validator抽象類的定義如下：

1 typedef struct _Validator{

2 bool (*const validate)(struct _Validator *pThis, int value);

3 }Validator;

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

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

>>>1.1.2 繼承

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

基于此，在將具有可變性的校驗參數(shù)分別轉(zhuǎn)移到RangeValidator和OddEvenValidator中的同時，并將Validator類型的變量isa作為結(jié)構(gòu)體的成員，即可創(chuàng)建新的結(jié)構(gòu)體數(shù)據(jù)類型：

1 typedef struct _Validator{

2 bool (*const validate)(struct _Validator *pThis, int value);

3 }Validator;

4 Validator *pThis;

5

6 typedef struct{

7 Validator isa; //繼承自Validator類

8 const int min;

9 const int max;

10 } RangeValidator;

11 RangeValidator rangeValidator;

12

13 typedef struct{

14 Validator isa; //繼承自Validator類

15 bool isEven;

16 } OddEvenValidator;

17 OddEvenValidator oddEvenValidator;

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

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

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

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

當開發(fā)者決定采用某種協(xié)作模式后，工作會被分解給對象，即在相應的類上定義適當?shù)姆椒?。歸根到底，單個類的協(xié)議包含了實現(xiàn)所有行為，以及實現(xiàn)與其實例相關的所有機制所需要的全部操作。因此與類層次結(jié)構(gòu)的設計一樣，機制代表了戰(zhàn)略的設計決策。

實際上，機制就是在長期的實踐中發(fā)現(xiàn)和總結(jié)的各種模式。在底層開發(fā)模式中，慣用法是一種表現(xiàn)形式；在高層開發(fā)模式中，則有一組類組成的框架?？蚣艽砹舜笠?guī)模的復用，比如，ZLG的AMetal框架和AWorks框架，MVC框架和MVVM框架以及微軟的.NET框架或開源代碼。所以機制代表了一種層次的復用，它高于單個類的復用。

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

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

其實繼承是一個非常傳統(tǒng)和經(jīng)典的術(shù)語，從Smalltalk問世時就被廣泛使用，將一般類和它的特殊類之間的關系稱為繼承關系。它在很多場合還以動詞或形容詞的面目出現(xiàn)。比如，特殊類繼承了一般類的屬性和操作，面向?qū)ο缶幊陶Z言具有繼承性和封裝性等。

而一般-特殊恰當?shù)匾话泐惡退奶厥忸愔g的相對關系，既可以稱為一般-特殊關系，也可以形成一般-特殊結(jié)構(gòu)。當“一般”這個術(shù)語generalization翻譯成中文時，很容易與上下文混淆，因此翻譯成“泛化”更準確。即一般類（父類）對特殊類（子類）而言是泛化，反之就是特化。因此一般類和特殊類之間的關系稱為一般-特殊關系，一般-特殊結(jié)構(gòu)是由一組具有一般-特殊關系（繼承關系）的類所形成的結(jié)構(gòu)。

顯而易見，一般-特殊結(jié)構(gòu)是問題域中各類事物之間客觀存在的一種結(jié)構(gòu)，在面向?qū)ο蠓治瞿Ｐ椭薪⒁话?特殊結(jié)構(gòu)，使模型更清晰地映射了問題域中事物的分類關系——將對象劃分為類，用類描述屬于它的全部對象實例。它將具有一般-特殊關系的類組織在一起，可以簡化對復雜系統(tǒng)的認識，使人們對系統(tǒng)的認識和描述更接近日常思維中一般概念和特殊概念的處理方式。

在面向?qū)ο蟮拈_發(fā)中，一般-特殊結(jié)構(gòu)可以使開發(fā)者簡化對類的定義，因而對象的共同特征只需在一般類中給出，特殊類通過繼承而自動地擁有這些特征，不必再重復定義。

不同的方法學對如何發(fā)現(xiàn)一般-特殊結(jié)構(gòu)，有不同的策略。其最大的問題讓人們感到更多地是依賴于直覺，如果分析方法是一門藝術(shù)，也就意味著讓人具有很大的不確定性。而事實上，使用共性和差異化分析工具，并從概念、規(guī)約和實現(xiàn)三個不同的視角看待對象，就可以簡化復雜的系統(tǒng)，詳見《嵌入式軟件工程方法與實踐叢書——面向?qū)ο蟮姆治雠c設計》。

>>>1.1.3職責驅(qū)動設計

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

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

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

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

不言而喻，OOP比POP更直接地表達了校驗器的共性：“使用validate函數(shù)指針在運行中根據(jù)對象的類型調(diào)用不同的函數(shù)，并通過pThis指針指向當前對象引用校驗參數(shù)將共同的部分打包在一起形成抽象類?！碑斔鼈冇辛诉@種共性時，則更容易討論各種校驗器相互之間的差別。

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

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

bool validateRange(Validator *pThis, int value);

bool validateOddEven(Validator *pThis, int value);

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

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

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

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

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

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

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

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

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

1 #include "validator.h"

2

3 bool validateRange(Validator *pThis, int value)

4 {

5 RangeValidator *pRangeValidator = (RangeValidator *)pThis;

6 return pRangeValidator -> min <= value && value <= pRangeValidator -> max;

7 }

8

9 bool validateOddEven(Validator *pThis, int value)

10 {

11 OddEvenValidator *pOddEvenValidator = (OddEvenValidator *)pThis;

12 return (!pOddEvenValidator -> isEven && (value % 2)) ||

13 (pOddEvenValidator -> isEven && !(value % 2));

14 }

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

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

● 在定義派生類（可變性）時，需要知道對于一個給定的特定實現(xiàn)（即變化），應該如何根據(jù)給定的規(guī)約實現(xiàn)它。

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

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

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

1 #pragma once;

2 #include

3

4 typedef struct _Validator{

5 bool (*const validate)(struct _Validator *pThis, int value);

6 }Validator;

7

8 typedef struct{

9 Validator isa;

10 const int min;

11 const int max;

12 } RangeValidator;

13

14 typedef struct{

15 Validator isa;

16 bool isEven;

17 } OddEvenValidator;

18

19 bool validateRange(Validator *pThis, int value); //范圍校驗器函數(shù)

20 bool validateOddEven(Validator *pThis, int value); //奇偶校驗器函數(shù)

21 #define newRangeValidator(min, max) {{validateRange}, (min), (max)} //初始化RangeValidator

22 #define newOddEvenValidator(isEven) {{validateOddEven}, (isEven)} //初始化OddEvenValidator

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

RangeValidator rangeValidator = newRangeValidator(0, 9);

宏展開后如下：

RangeValidator rangeValidator = {{validateRange}, (0), (9)};

其中，外面的{}為RangeValidator結(jié)構(gòu)體賦值，內(nèi)部的{}為RangeValidator結(jié)構(gòu)體的成員變量isa賦值。即：

rangeValidator.isa.validate = validateRange;

rangeValidator.min = 0;

rangeValidator.max = 9;

如果有以下定義：

Validator *pValidator = (Validator *)&rangeValidator;

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

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

Validator * pValidator = &rangeValidator.isa;

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

pValidator -> validate(pValidator, 8);

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

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

>>>1.1.4 多態(tài)性

多態(tài)性是面向?qū)ο蟪绦蛟O計的一個重要特征，多態(tài)（函數(shù)）的字面含義是具有多種形式。每個類中操作的規(guī)約都是相同的，而這些類可以用不同的方式實現(xiàn)這些同名的操作，從而使得擁有相同接口的對象可以在運行時相互替換。

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

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

多態(tài)是一種運行時基于對象的類型發(fā)生的綁定機制，通過這種機制實現(xiàn)函數(shù)名綁定到函數(shù)具體實現(xiàn)代碼的目的。當執(zhí)行一個程序時，構(gòu)成程序的各個函數(shù)分別在計算機的內(nèi)存中擁有了一段存儲空間，一個函數(shù)在內(nèi)存中的起始地址就是這個函數(shù)的入口地址，因此多態(tài)就是將函數(shù)名動態(tài)綁定到函數(shù)入口的運行時綁定機制。盡管多態(tài)與繼承緊密相關，但通常多態(tài)被單獨看作面向?qū)ο蠹夹g(shù)最強大的一個優(yōu)點。

顯然，調(diào)用校驗器就是發(fā)送一個消息，它要使用validate函數(shù)指針。實際上無論范圍值校驗器還是奇偶校驗器，其校驗過程都是由不同內(nèi)容的函數(shù)實現(xiàn)的。在面向?qū)ο蟮木幊讨?，在不同的類中定義了其響應消息的方法，那么在使用這些類時，則不必考慮它們是什么類型，只要發(fā)布消息即可。正如在調(diào)用校驗器時，不必考慮其調(diào)用的它們是什么校驗器，直接使用validate函數(shù)指針，無論什么類型校驗器都能實現(xiàn)檢查功能。

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

圖 4.5 抽象類的層次結(jié)構(gòu)

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

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

bool pushWithValidate(stackADT stack, int value, Validator *pValidator);

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

pushWithValidate()的具體實現(xiàn)如下：

1 bool pushWithValidate(stackADT stack, int value, Validator *pValidator)

2 {

3 if (pValidator && !pValidator -> validate(pValidator, value)){

4return false;

5 }

6 return push(stack, value);

7 }

其調(diào)用形式如下：

pushWithValidate(stack, 8, &rangeValidator.isa);

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

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

1 #include

2 #include"Stack.h"

3 #include"validator.h"

4

5 bool pushWithValidate(stackADT stack, int value, Validator *pValidator)

6 {

7 if (pValidator && !pValidator -> validate(pValidator, value)){

8 return false;

9 }

10 return push(stack, value);

11 }

12

13 int main(int argc, int *argv[])

14 {

15 stackADT stack;

16 int temp;

17

18 stack = newStack();

19

20 RangeValidator rangeValidator = newRangeValidator(0, 9);

21 for (int i = 0; i < 16; i++){?

22 pushWithValidate(stack, i, &rangeValidator.isa);

23 }

24 while(!stackIsEmpty(stack)){

25 pop(stack, &temp);

26 printf("%d ", temp);

27 }

28 printf(" ");

29 OddEvenValidator oddEvenValidator = newOddEvenValidator(true);

30 for (int i = 0; i < 16; i ++){?

31 pushWithValidate(stack, i, &oddEvenValidator.isa);

32 }

33 while (!stackIsEmpty(stack)) {

34 pop(stack, &temp);

35 printf("%d ", temp);

36 }

37 freeStack(stack);

38 return 0;

39 }

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