介紹幾種特殊的類型設(shè)計
1、缺失行為的對象。
缺失行為，換一種特殊類型設(shè)計說法就是什么都不能的對象，如同我在上一篇文章中舉的石頭的例子一樣，沒有任何行為的對象是可以合理存在的。當(dāng)然，string的那個例子可能不夠好，因為string或者說int等等純數(shù)據(jù)類型，不會出現(xiàn)在OOD中。但這種缺失行為的對象也并非罕見，常見于定義數(shù)據(jù)規(guī)范的對象：如ConnectionString、Uri、IPAddress，實際領(lǐng)域中，OA中的Document、Enterprise中的Order，用戶體系中Account、IIdentity、IPricipal這樣的對象，WebApplication中的Session。如果你仔細(xì)去找，這類型的對象其實非常多，在大多數(shù)領(lǐng)域中都有可能出現(xiàn)。
當(dāng)然，上面局的例子的每一種，某些東西的狂熱擁護(hù)者都能舉出反面例子，就像說明string也有方法一樣。但，方法不等于行為，正如同不會有人將屬性視為行為一樣，但屬性是方法來實現(xiàn)的。
給connectionString加上OpenConnection的方法或是給Account加上Logout的方法，抑或者Order的Seal或Sign方法，都不能說是一個好的Design，在我看來就是畫蛇添足。
2、缺失數(shù)據(jù)的對象。
缺失數(shù)據(jù)，換一種特殊類型設(shè)計說法就是什么都沒有的對象。缺失數(shù)據(jù)不一定說是沒有成員變量，而是外部不可見，不可讀也不可寫。當(dāng)然也不排除真的沒有任何成員變量的情況，但這個不是問題的重點。正如同上一篇文章中某個回復(fù)說的一樣：“如果我們真的只需要一把刀，那么就造一把刀就可以了”。這樣的對象在OOD中也是存在的，比如說監(jiān)聽事件并主動記錄的Logger，審核權(quán)限的Auditor，這些對象都不需要自己有什么數(shù)據(jù)，別人也不關(guān)心他們有什么，只需要知道它們能干什么就行了。
3、行為和數(shù)據(jù)都沒有的對象。
換一種特殊類型設(shè)計說法什么都沒有，什么都不能的對象，這種情況比較極端，但只要類型有意義，即使行為和數(shù)據(jù)都沒有，這個類型本身就能構(gòu)成其存在的意義。除了標(biāo)記接口，這樣的對象極為罕見，舉一個可能并不是很恰當(dāng)?shù)膱鼍埃?/P>
有三種貨物：豬肉、魚肉和雞肉，然后他們都是一份份的，每一份豬肉、每一份魚肉以及雞肉都是一樣的，但豬肉、魚肉雞肉之間并不相同。
我們有幾個倉庫，然后倉庫有這么一個行為，把一份貨物放進(jìn)去，但每種貨物放進(jìn)去的時候都要引發(fā)不同的行為。
當(dāng)然，我們可以寫三個方法，但更好的做法是寫同一個方法的三個重載。當(dāng)然直到這里，必須設(shè)計成三種類型看起來仍然沒什么必要，但是如果我們再增添種種操作，例如倉庫之間可以調(diào)配貨物，根據(jù)貨物選擇加工員，設(shè)計為三種類型就能利用靜態(tài)聯(lián)編等手段大大的簡化代碼。
更進(jìn)一步，在以后可能會提出需求要跟蹤貨物在倉庫之間調(diào)配的過程并計算中間的不合理損耗，這樣的情形下，一開始設(shè)計成三種類型就會很有幫助，盡管在一開始看起來這是一件很傻的事情。換言之，這樣的對象在設(shè)計中存在的意義可能更多的是為以后重構(gòu)做準(zhǔn)備。
在設(shè)計中，可能更常見的是不關(guān)心對象的行為和數(shù)據(jù)。例如容器對象不關(guān)心里面儲存的容器項有什么行為和數(shù)據(jù)，序列化器不關(guān)心被序列化的對象有什么行為和數(shù)據(jù)。我們做一個模塊的設(shè)計，這個模塊就可能有不關(guān)心數(shù)據(jù)和行為的對象。
4、缺失標(biāo)識。
缺乏標(biāo)識，即類型無意義的類，不應(yīng)出現(xiàn)在在設(shè)計中，在編程中可以靈活加以運用。
常見的有，Math、HttpUtility為代表的工具類（函數(shù)集），只包含常量的常量集類?；蛟S你可以說HttpUtility是“關(guān)于http的工具箱”，但Math卻很難去說這是什么東西，數(shù)學(xué)手冊？關(guān)于數(shù)學(xué)的工具箱？還是計算器？
廣義一點，用于輔助實現(xiàn)的類，也可以認(rèn)為是類型沒有意義的，如Wrapper、Builder、Adapter、Factory等，因為它們本身并不是一個什么東西，而是為了某個目的而創(chuàng)造出來的?；蛘哒f屬于編程技巧而不是設(shè)計技巧。行為、數(shù)據(jù)都沒有，類型也沒有意義的類可以認(rèn)為不存在。繼續(xù)，談?wù)剮追N看起來不合常理的設(shè)計：
5、派生類屏蔽基類方法。
應(yīng)該說這種情況不會常見，派生類與基類的關(guān)系是抽象的關(guān)系，基類必須比派生類更抽象。一般而言，具體的對象應(yīng)該比抽象的對象擁有更多的功能。但在某些特殊情況下，多出來的卻是限制，如同癱瘓的貓的例子一樣。因為特殊情況并不多見，遇到這種情況的時候，仔細(xì)思考抽象的基類被屏蔽的方法是不是一個普適的行為，例如所有寵物都會拿耗子顯然是荒謬的。如果被屏蔽的方法并不是一個普適的行為（例如沒有或者很少直接用基類對象來調(diào)用這個方法），考慮將其刪除或者修改為protected。但在任何時候都應(yīng)當(dāng)記住，派生類不一定要比基類多一些功能，基類必須比派生類抽象是繼承的原則，不能因為派生類功能少基類功能多而去顛倒繼承方向，繼承的目的不在于代碼重用。具體的例子其實很多，比如說HttpWebRequest等。
6、很少，甚至沒有代碼的派生類。
這是一個很有意思的話題，如同剛剛說的沒有數(shù)據(jù)和行為的對象一樣，一個對象只要類型有意義在很多時候就是存在的充分條件。沒有代碼的派生類意味著不會給基類增加任何功能。因為派生類與基類的關(guān)系是具體和抽象的關(guān)系，只要類型攜帶的信息更具體了，即使不增加任何東西也是合理的。具體的例子，比如ASP.NET中的PlaceHolder。因為它所需要具備的功能（充當(dāng)其他控件的容器）已經(jīng)被基類Control完全的實現(xiàn)了。所以它就不需要任何代碼了。但它比Control具體卻是很顯然的。
幾種特殊類型設(shè)計的總結(jié)
OOD不是三言兩語，幾個原則，幾個案例就能說清楚的事情，理解，以及實踐加上漫長的過程才能從OOP的領(lǐng)域邁向OOD的境界。這篇以及上篇文章主要我所希望表達(dá)的，并不是想說OOD是什么玄之又玄，存乎一心的東西。其實想說的東西也很老套，任何一個規(guī)則都有其背景和場景，千萬不要認(rèn)為所有的規(guī)則都是普適的，搞清楚背后的故事很重要。
你有一個良好的編程習(xí)慣，懂得靈活運用各種設(shè)計模式，這只是說明你具有一定的OOP水平了而已。正如同上面所說的，一個類（對象）只要其類型是有意義的，其存在就有意義，OOD要求從類型而不是其成員入手。這是一種抽象的藝術(shù)，盡管我很希望能夠找到一句簡單的話讓大家可以一下子茅塞頓開從OOP一下跳到OOD的層次。但很可惜，我沒找到。。。。。
【編輯推薦】
