設計的核心任務之一：層次的控制

對於軟體而言，層次是讓人又愛又恨的東西。

 

很多問題是通過增加層次解決的，但另外一部分問題也是因為層次而匯入的。我們來分別看幾個例子。

 

例1：很多時候我們並不希望最終的應用綁定於某個指定平台，比如:Windows。為了達成這種跨平台的目的，就需要在OS和應用之間加入一個中介層，這個中介層負責屏蔽不同OS的差異。實際上，Java虛擬機器等走的都是這樣一條路線。

 

例2：當使用XML檔案儲存配置資訊的時候，我們並不希望XML的結構在整個程式中隨處可見。比如說：現在我們在Configuration/OutputFolder節點下儲存了預設儲存目錄，但將來很可能節點變成了Configuration/OutputFolder/Save。為了斬開與XML結構的關聯，那麼我們需要加入一個新的抽象層，來表徵XML檔案，再通過GetSaveFolder()這樣的方法對預設儲存目錄進行擷取。

 

通過加入層次解決問題的同時，新的問題也隨之發生。在眼前蒙上一層薄紗可以防止眼睛被風沙所傷害，但如果蒙上十層，那更嚴重的後果將會出現---你看不到路了。

 

從可理解的角度看，只有某一功能所涉及的所有層次，所關聯變數的各種可能性都被澄清之後，具體的代碼才可能真的被理解。在排錯的時候尤其如此。我們來看一個例子：

 

在用C++建立集合類的時候，我們可能希望對集合類的記憶體使用量方法進行更多的定製。

有時候我們可能想預先保留一塊記憶體，接下來在這塊記憶體上進行二次分配來存放各種小的對象。

有時候我們也可能想直接在磁碟上分配空間存放放入集合類的對象。

為了達成上面這些目的，層次又一次站出來發揮作用，我們可以建立allocator這樣的類來建立一層抽象，建立集合類的時候，可以通過指定不同的allocator來控制記憶體使用量的方法。

 

這應該是不錯的設計方法，C++標準模板庫裡就是這麼做的。

接下來我們來看一旦出了錯的情形。

我們可能希望放入集合類的對象總是進行淺拷貝(swallow copy)，為此重載了類的拷貝建構函式和賦值函數，但最終發現當對象被放入集合類的時候，不知道為什麼總是不成功。

 

這個時候，邏輯上程式沒有任何問題，因此只靠腦子想是完全解決不了問題了。為了排錯，我們只能啟動調試器。

調試的過程中，我們通常並不能一下就確認問題和allocator究竟有沒有關聯，所以為了找出問題所在，我們也要對allocator這一層次做點分析。這種分析的開銷事實上就成為添加allocator這一層次的代價。

 

通過上述的例子我們可以大致體會到層次這把雙刃劍的威力。

 

通過層次我們可以讓軟體更靈活，抽象更充分；但層次也會把達成某一功能所必須的資訊進行分割，增加複雜度。所以層次的多少往往並非是一個對與錯的問題，而是一個程度問題，究竟什麼樣的層次才合適，是需要現場的人進行判斷的。

曾經有人說過這樣一句話，可供我們參考，他說：如果你知道自己在做什麼三層足夠；如果你不知道自己在做什麼，那麼十七層也沒用。

我個人是認同這一觀點的，除非特別的情形，要努力控制層次在三層左右，否則寧願犧牲一點抽象。

 

和層次相關的問題主要有兩個：一個是層次的多少；另一個則是層次的一致性。如果說層次的多少是一個合適與否的問題，那麼層次一致性則是一個是非問題。

某一個層次上所體現出來的東西應該具有層次一致性。

 

這和前面在討論的需求中的層次問題類似。

比如說：如果有一個類叫Cat，那這個類的介面，可以有返回貓的顏色，貓的種類，這些屬性是在一個抽象層面上的。但如果突然有一個介面是返回貓的個數，那麼大多時候就會讓人感到奇怪。

我們感覺到奇怪的本質原因是抽象的層次出現了不一致性。顏色和種類這種屬性屬於具體的某一隻貓，而個數則屬於貓的集合。

 

這種抽象層次的不一致實際上是增加耦合度的一個主要元兇。

 

很不幸的是，這又是一個要依賴於個人技能的地方。眼下還看不到自動判斷抽象層次是否合適的方法。