介紹一部分類和接口的高質(zhì)量設(shè)計(jì)的準(zhǔn)則。這些準(zhǔn)則不但應(yīng)該保證設(shè)計(jì)并且實(shí)現(xiàn)的類或者接口本身有高質(zhì)量代碼，而且更重要的是在工業(yè)領(lǐng)域應(yīng)該盡可能的使代碼的更新和維護(hù)不影響客戶的活動(dòng)，主要也就是保持二進(jìn)制代碼兼容(binary compatibility)和源代碼兼容(source compatibility)。我希望這些準(zhǔn)則能幫助剛從學(xué)校進(jìn)入工業(yè)領(lǐng)域的朋友盡快適應(yīng)更高標(biāo)準(zhǔn)的編程要求，盡快提升自己的設(shè)計(jì)能力。
文中以C++類的設(shè)計(jì)為討論范圍。
總提 面向?qū)ο缶幊虒τ诋a(chǎn)出高質(zhì)量，易維護(hù)的代碼是非常有幫助的。面向?qū)ο缶幊痰母拍顦?gòu)建于三個(gè)基本特征之上：封裝，繼承，多態(tài)。在C++中，class是面向?qū)ο缶幊谈拍畹暮诵暮途唧w形式。class通過私有成員體現(xiàn)“封裝”，通過直接繼承或者組合體現(xiàn)“繼承”，通過虛函數(shù)和動(dòng)態(tài)綁定(dynamic binding)體現(xiàn)“多態(tài)”。class的設(shè)計(jì)質(zhì)量直接決定了整個(gè)系統(tǒng)的質(zhì)量。
從整體功能層面談class設(shè)計(jì)，有這么三條原則：
·單一功能原則(Single Responsibility Principle) 一個(gè)class就其整體應(yīng)該只提供單一的服務(wù)。如果一個(gè)class提供多樣的服務(wù)，那么就應(yīng)該把它拆分，反之，如果一個(gè)在概念上單一的功能卻由幾個(gè)class負(fù)責(zé)，這幾個(gè)class應(yīng)該合并。
·開放/封閉原則(Open/Close Principle) 一個(gè)設(shè)計(jì)并實(shí)現(xiàn)好的class，應(yīng)該對擴(kuò)充的動(dòng)作開放，而對修改的動(dòng)作封閉。也就是說，這個(gè)class應(yīng)該是允許擴(kuò)充的，但不允許修改。如果需要功能上的擴(kuò)充，一般來說應(yīng)該通過添加新類實(shí)現(xiàn)，而不是修改原類的代碼。添加新類不單可以通過直接繼承，也可以通過組合。
·最小驚訝原理(Least Surprise Principle) 在重載函數(shù)，或者子類實(shí)現(xiàn)父類虛函數(shù)時(shí)，應(yīng)該基本維持函數(shù)原來所期望的功能。比如：
以下是代碼片段：
class Pet {
public:
virtual Talk() = 0;
};
class Cat : public Pet {
public:
void Talk() { cout << "miao"; }
};
class Dog : public Pet {
public:
void Talk() { BiteOwner(); }
}; |
class Dog 在實(shí)現(xiàn)虛函數(shù)Talk的時(shí)候，沒有像我們期望的那樣輸出狗吠聲，而是咬起主人來了。這是應(yīng)該避免的。
接口和實(shí)現(xiàn) 在系統(tǒng)中，觀察一個(gè)class有兩個(gè)角度，從外部或者用戶角度我們看到的是接口，從內(nèi)部我們看到的是實(shí)現(xiàn)。因?yàn)橄到y(tǒng)肯定要不斷修改，因此實(shí)現(xiàn)免不了不停的變化，但是接口又被要求盡量保持穩(wěn)定。這兩者的矛盾必須通過良好的設(shè)計(jì)盡量避免，基本原則就是將實(shí)現(xiàn)細(xì)節(jié)與接口隔離。下面列出幾條比較具體點(diǎn)的：
·接口的設(shè)計(jì)保持最小而完整
精簡接口函數(shù)個(gè)數(shù)，使每一個(gè)函數(shù)有代表性，函數(shù)功能恰好覆蓋class的職能。一個(gè)最小的接口可以使維護(hù)簡單，增加潛在的代碼重用性，減少客戶的迷惑，并且也可以縮小頭文件長度和編譯時(shí)間。當(dāng)改進(jìn)函數(shù)時(shí)，應(yīng)該用類似函數(shù)名實(shí)現(xiàn)改進(jìn)而保留原函數(shù)，代碼注釋里應(yīng)該有相應(yīng)的說明。可以增加新函數(shù)，但不能刪除舊函數(shù)。
·成員變量應(yīng)該都為私有
顯而易見，public變量破壞封裝性以及接口和實(shí)現(xiàn)的分離；protected變量也可能使客戶編寫繼承類而依賴于父類的實(shí)現(xiàn)細(xì)節(jié)。
·避免函數(shù)返回成員變量的指針或引用
這么做也會(huì)使客戶代碼依賴于實(shí)現(xiàn)細(xì)節(jié)。
·考慮是否禁用編譯器缺省產(chǎn)生的函數(shù)
這些函數(shù)包括：復(fù)制構(gòu)造函數(shù)，賦值操作符(operator =)。如果我們不打算定義自己的版本而不禁用默認(rèn)版本的話，可能使客戶代碼在不注意的情況下調(diào)用這些函數(shù)。當(dāng)實(shí)現(xiàn)發(fā)生改動(dòng)時(shí)就可能引起問題，比如class多了一個(gè)heap memory指針。如果我們允許對象拷貝，比較穩(wěn)妥的方法是禁用它們，而定義一個(gè)專門的clone()函數(shù)。
兼容性(compatibility) 不用說，兼容性是非常重要的。Intel和Microsoft之所以如此成功，其中一個(gè)重要方面就是他們的產(chǎn)品，不管是硬件還是軟件，都做到了很好的兼容老產(chǎn)品。代碼的兼容也是如此。難以想象，如果客戶依賴于你的library產(chǎn)品，而要因?yàn)槟愕漠a(chǎn)品的更新而不斷的重寫他的代碼，他還會(huì)繼續(xù)用你的產(chǎn)品。
代碼兼容可以簡單分為二進(jìn)制兼容和源代碼兼容。二進(jìn)制兼容也就是說，客戶的已編譯代碼可以在不用重新編譯的情況下，直接使用你的不同版本的已編譯代碼。源代碼兼容就是，如果你的代碼更新了，客戶的代碼不需要修改，只需要重新編譯就可正常運(yùn)行。在C++中，接口一般是由頭文件和library二進(jìn)制代碼提供，因此，任何可能造成library代碼和舊的頭文件不一致的情況都可能破壞二進(jìn)制兼容，因?yàn)榭蛻舸a必須和新的頭文件重新編譯一次。
因此，遵循幾條準(zhǔn)則可以使你更輕松地解決兼容性問題：
·不改變類的大小或者改變成員變量的順序
包括幾個(gè)方面：不增加或減少成員變量；不修改成員變量類型；不改變成員變量的聲明順序；不改變虛函數(shù)的有無。顯而易見，增加或減少成員變量會(huì)改變類的大小，并且需要更新頭文件，從而可能造成與客戶代碼不兼容。類型的變化也可能引起類的大小的變化。成員變量的訪問一般是由編譯器按偏移量確定，順序如果改變，偏移量也就會(huì)改變，破壞了二進(jìn)制兼容。至于虛函數(shù)的有無，決定是否存在虛函數(shù)表指針，也就影響了類的大小和成員變量的順序。
·不使用inline函數(shù)
inline函數(shù)聲明于頭文件中，并且被編譯于客戶代碼中，如果inline函數(shù)訪問了private成員，該成員又改變了順序，那么inline函數(shù)虛要被重新編譯，破壞了二進(jìn)制兼容。
·接口函數(shù)不使用虛函數(shù)
虛函數(shù)的訪問和成員變量類似，是通過虛函數(shù)表中的偏移。虛函數(shù)順序的改變會(huì)影響偏移。因此，在條件允許時(shí)，應(yīng)該避免使用public虛函數(shù)。比如：
以下是代碼片段：
class Picture {
public:
virtual void Draw();
};
應(yīng)該改為
class Picture {
public:
void Draw();
private:
virtual void DoDraw();
};
void Picture::Draw()
{
DoDraw();
} |
·不改變接口函數(shù)的順序
在很多嵌入式系統(tǒng)中，鏈接庫通過輸出函數(shù)表(exported function table)暴露接口以節(jié)省空間。此時(shí)，對接口函數(shù)的訪問也是通過索引值進(jìn)行，因此改變順序也會(huì)破壞兼容性。
·避免使用函數(shù)缺省參數(shù)
給函數(shù)形參設(shè)定缺省值可以方便客戶，但是可能破壞兼容。缺省值隨頭文件給出，缺省值的改變也就會(huì)引起兼容問題。