近期整合靜態工廠、工廠方法和抽象工廠模式。因為我很厭惡dip，所以仔細看了一下《head first 設計模式·4工廠模式》。
乙個字評價爛，兩個字，超級爛。
這本書的行文風格，各有喜好，我不評價——雖然我不喜歡花裡胡哨的插圖等。我們看其內容。
不應該用new，這節沒有問題。《識別變化的方面》給出乙個很爛的例子。pizzastore與pizza。抽象類pizza有一系列子型別如cheesepizza等等；pizzastore要依賴抽象類pizza，因此將建立pizza物件的工作交給******pizzafactory很容易理解。有一點要注意，通常******pizzafactory的工廠方法設計成靜態的(沒有理由讓它為例項方法，該書似乎準備為工廠方法模式做準備，所以搞成例項方法)。
為什麼說這是很爛的例子？pizzastore->pizza，可以用client-iserver關係加以一般化，可以隨便地舉例，如人依賴抽象類「交通工具」。現在pizzastore->pizza關係問題不大。關鍵在後面。
《加盟比薩店》我首先想到的是，pizza的子型別成為地域與風味的叉乘，如果有2個城市，4種風味，pizza需要8個子類。（型別**）
而《我們已經有乙個做法...》，以******pizzafactory為父類，有了三個引數化工廠nypizzafactory等。這樣也可以。
《但是你想要多一些質量控制...》開始顯得奇怪了。你講物件的建立，為什麼要提到模板方法模式和框架？好像作者為了把pizzastore設計成工廠，在胡亂地找藉口。也就是說，因為pizzastore有乙個模板方法定義了製作比薩店流程，所以把pizzastore設計成工廠。（前面pizzastore與pizza中間，加了******pizzafactory。現在又胡亂地找藉口，想把pizzastore設計成工廠）。
package init.factory;
public abstract class pizzastore
abstract pizza createpizza(string type);
}
為什麼說這是很爛的例子？如果人->「交通工具」。交通工具有子類汽車、單車，那麼交通工具和修理廠的關係，很容易說明交通工具和修理廠要一一對應，交通工具將作為修理廠的工廠。汽車修理廠修理汽車....而在pizzastore->pizza例子中，正好相反，相當於修理廠->交通工具(pizzastore->pizza),而交通工具按照價位可以分成高中低擋（pizza有地域風格），於是作者把修理廠作為工廠，有高檔修理廠(紐約pizzastore)等子型別，而高檔修理廠可以修理高檔汽車和高檔單車。正因為不自然，作者在這裡提到模板方法模式、框架和dip。
總之，我個人覺得《head first 設計模式·4工廠模式》寫得沒有一點水平，超級稀爛。
從結果看，正確的設計的確是pizzatestdrive依賴披薩店/pizzastore而pizzastore正好作為pizza的工廠，因為nypizzastore生產ny風格的比薩。正如我說的，工廠方法模式要解決型別匹配問題。
headfirst設計模式
花了一周多一點的時間看完了headfirst的設計模式。看完之後有一種恍然大悟的感覺，仔細想想有覺得自己好像什麼也看懂。簡單說下對這本書的一點感悟吧，headfirst的書比較通俗易懂，之前看了四人幫的設計模式，看一半就有一種痛不欲生的感覺，自己水平有限，看不懂，也就沒在勉強自己了。對於模式其實簡單...
HeadFirst 設計模式學習筆記4 工廠模式
1.我們在前邊提到乙個原則就是 面向介面而不要面向實現程式設計 但是我們一直在使用duck duck new mallardduck 這樣的模式，後邊的new語句卻違反了這個原則。工廠方法就可以解決這個問題，它用來封裝物件的建立。2.這一節我們考慮如下場景 乙個披薩店要製作各種各樣的披薩，甚至還要開...
HeadFirst 設計模式學習筆記4 工廠模式
1.我們在前邊提到乙個原則就是 面向介面而不要面向實現程式設計 但是我們一直在使用duck duck new mallardduck 這樣的模式，後邊的new語句卻違反了這個原則。工廠方法就可以解決這個問題，它用來封裝物件的建立。2.這一節我們考慮如下場景 乙個披薩店要製作各種各樣的披薩，甚至還要開...