說起這個工廠模式，一時還真不知道該如何說起。反正這是我的開發日志，不提理論的東西，理論的東西那里都有，我只想把具體實踐記錄下來給師弟師妹們作個參考，積累點經驗。所有這些文字都是集中講一點――“在什么情況下為什么用某種模式好，為什么好，為什么在那種情況下能想起來用？”。
研究生院項目中“明顯”使用了“工廠方法模式”。其實在遇到具體問題的時候，即使我們不知道有這個模式存在，我們也肯定會造一個類似的東西出來。但是，肯定沒有書上論述的那么好，那么全面。我想這就是看書的好處吧。
工廠方法出現的必然（我的理解，一個很狹隘并幼稚理的人的理解）
剛開始使用這個東西的時候，只是感覺是單純的一種模式，用于創建需要的對象。
但是隨著使用和思考的深入，越發發現它給我的啟示不只在于單純的對象創建，而是告訴我應該怎么理解“產品”，怎么得到“產品”，怎么消費“產品”，以至于以后怎么設計“產品”。
下面這個線索是我對它出現必然性的理解：
1. “針對接口編程”
這是OO世界中經典的規范，不管你主動還是被動，你天天都在用這個東西。
接口是共性的表示，在對象的世界中，共性和個性的辯證關系是最重要的關系。在萬千的對象中，通過它們之間的共性和個性，可以形成最基本對象層級架構。
假設我們的討論域中有以下一些對象：“學生”、“大學生”、“小學生”、“中學生”；我們不用細想，學過一天OO的人都可以為這些耳熟能詳的對象們，通過個性和共性的關系得出下面的結構圖。
把這些對象之間的關系定義成這樣是順理成章的。
下一步肯定是讓客戶端“使用”這個接口啦。也就是如下圖：
2. 接口和具體類的矛盾
勿庸置疑，我們只希望Client跟接口Student打交道，讓它根本就不知道Student有哪些子類，絕對不希望直接跟它們打交道。
但這里出現的困難是，接口都是“假”的，都是由具體類upcast的。
如果Client要使用接口Student，Client中必須會出現下面的代碼：
Student marco = new Small_Student();
只要一出現這個代碼，就說明Client不只跟Student打交道了，它知道了Small_Student類，這違反了我們預先的想法。
3. 找“人”幫我去創建“接口對象”
從上圖體現出來的結構看，Client只想跟Student打交道的目的是實現不了的了。
最簡單的方法就是找另外的“幫手”去幫我生成這個“接口對象”。這個幫手它知道“接口對象”的具體類型，但是它為客戶端提供的卻一定是“接口類型”。這就符合我們的要求了。如圖：
這樣，Client就可以既用到了“Student接口對象”，又不用因為“只有具體類才能創建對象”的規則，而必須對其子類結構有完全的了解。它成功的解決了2中的矛盾。
而“負責創建具體類對象的任務”全部都落在了這個“幫手”身上，這個“幫手”（Student_Factory）就是工廠模式中的工廠類，更具體的說，它就是“簡單工廠模式”中的“簡單工廠類”。
我覺得，即使一點都不知道工廠模式，一旦我遇到了2里說的矛盾，我也會用這樣的方法處理。
4. 這個“幫手”不符合“開－閉原則”
這個幫手的確不錯了，而且一躍成為系統中最重要的對象了，所有“創建具體類的邏輯”都放進去了，也就是因為重要，萬一掛了不就慘了。
再者，它不符合“開－閉”原則，我不能在不修改這個幫手的情況下添加任何一個產品。在這個例子中就是，如果那天我有病非要加一個“幼兒園學生”進來，那您就必須修改這個“幫手”的代碼了，這個“幫手”現在就變成Version2（如下圖）了，這個二版的幫手，可以在“代碼”層實現對一版（還沒有添加幼兒園學生之前)的通用，但這種保證在“開－閉”原則看來，還是不夠的，不保險的，它要的是在類的結構上的保證。聲明一下，這是我很感性的理解，不正確的可能性很高。
5. 讓“幫手”也多態
這里可以嘗試讓“幫手”也多態一下，這樣“每種學生類創建的任務”都被分派到了多態出來的類中去了。這時，再有新的學生類型加進來，添加一個對應的幫手就可以了。這樣雖然類多了一些，但是符合“開－閉”原則，書上稱之為“工廠方法模式”。如圖：
假如Client現在要使用一個小學生，代碼如下：
1
//創建一個小學生工廠類這個幫手
2 Student_Factory factory = new Small_Student_Factory();
3 //求助這個幫手，幫我創建一個
4 Student primaryStudent = factory.produce();
5 //這時就可以使用這個小學生了，讓它玩玩游戲吧
6 primaryStudent.playGames();
7
在這里還是要強調兩點：
n 雖然實際上Client的確使用了一個小學生對象（Small_Student），但這里Client也認為它就是Student對象，這里一定要用Student接口來隱藏它的具體類。
n 另外，卻不需要用Student_Factory這個接口來隱藏它的具體類，因為，Client實際就是通過“選擇它的具體類”這招兒來“選擇創建的學生類型”。這里的Student_Factory更多的功能不是“隱藏”具體類，而是“規范”具體類。
項目實踐
扯淡到此，該聯系我們的項目啦。
由于是做研究生院的項目，其中巨大的需求就是要讓同學能在網上提交各種申請單，申請退學的，申請轉專業的，申請復學的，申請保留學籍的，除了申請女朋友的外，應有盡有。 對于這些單子，用最最基本OO思維，根據共性個性分析方式，抽象出一個申請單接口，和若干的具體類。
當然，除了概念上感性上吻合以外，在項目中它們也要“真”的有巨大的共性才行，如都要提交，修改，刪除，審核，打印等功能。
靠，既然都這樣了，肯定就用一接口規定它了。
想到這里，加上有了上面的思考，不用說了，就用工廠方法模式啦。
圖中Ent_Shift就是申請單接口。等于前面分析的Student接口。還可以看到有很多具體類，前面例子中是代表各種學生，這里就是代表各種申請單。
當然，這里還有很多工廠，也就是前面一直叫的“幫手”。
Bean_Shift就是工廠接口，相當于前面的Student_Factory接口。還有很多的具體類就是生產各種申請單的工廠類。
下面就是使用“申請單工廠方法模式”的一段客戶端代碼：
1 //聲明申請單接口
2 Ent_Shift es = null;
3 //聲明申請單工廠接口
4 Bean_Shift bs = null;
5 //根據傳入的申請單類型數字身成對應的申請單工廠
6
switch (shiftTypeID) 
{
7
case Bean_Shift.SHIFT_CHANGETEAAP :
8 bs = new Bean_Shift_CHANGETEAAP();
9 break;
10 case Bean_Shift.SHIFT_RESERVEAP :
11 bs = new Bean_Shift_RESERVEAP();
12 break;
13 case Bean_Shift.SHIFT_RENEWAP :
14 bs = new Bean_Shift_RENEWAP();
15 break;
16 //省略了別的申請單……………………
17 default :
18 this.forwardErr(req, resp, "所選擇的異動類別不存在");
19
}
20
21 try {
22 //調用工廠接口的生產方法
23 es = bs.getBlankShift(stuID);
24
25 } catch (Exception e) {
26 this.forwardErr(req, resp, DB_ERROR);
27 }
28 //調用單子的提交方法
29 es.submit(req);
30
31 //發給頁面去顯示
32 es.fowrardWithSessionObject(
33 req,
34 resp,
35 Ent_Shift.nameInSessionAndRequest);
36
升華
個人比較同意《Design Pattern Explained》中作者講的，要用好很多的模式，其中都有一個思路，就是用接口或抽象類來隱藏子類的不同。
我每當看到這時，老是會被一種思路困擾――“new只能new具體類啊，這咋能隱藏呢，這隱藏還有什么用呢？”。
作者仿佛也曾經有過我的這個傻B苦惱，它的解決方法就是：根本在使用對象的時候，特別是設計階段，盡量不去想對象是在那里被new的。他認為：反正有了工廠模式后，你總有辦法把他們new出來的。
所以，我用了工廠模式后更發的啟發是：以后設計的時候不要想一個Client怎么創建一個對象，盡管放心大膽的先繼續想，直接使用就好了。反正最后我還有工廠模式呢。
因此俺的副標題才是“Ignore how they were created”，呵呵。
MARCO ZHANG 2006年2月16日3:52:10 