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