8.3 工廠方法模式的應用 8.3.1 工廠方法模式的優點 首先，良好的封裝性，代碼結構清晰。一個對象創建是有條件約束的，如一個調用者需要一個具體的產品對象，只要知道這個產品的類名（或約束字符串）就可以了，不用知道創建對象的艱辛過程，降低模塊間的耦合。 其次，工廠方法模式的擴展性非常優秀。在增加產品類的情況下，只要適當地修改具體的工廠類或擴展一個工廠類，就可以完成“擁抱變化”。例如在我們的例子中，需要增加一個棕色人種，則只需要增加一個BrownHuman類，工廠類不用任何修改就可完成系統擴展。 再次，屏蔽產品類。這一特點非常重要，產品類的實現如何變化，調用者都不需要關心，它只需要關心產品的接口，只要接口保持不變，系統中的上層模塊就不要發生變化。因為產品類的實例化工作是由工廠類負責的，一個產品對象具體由哪一個產品生成是由工廠類決定的。在數據庫開發中，大家應該能夠深刻體會到工廠方法模式的好處：如果使用JDBC連接數據庫，數據庫從MySQL切換到Oracle，需要改動的地方就是切換一下驅動名稱（前提條件是SQL語句是標準語句），其他的都不需要修改，這是工廠方法模式靈活性的一個直接案例。 最后，工廠方法模式是典型的解耦框架。高層模塊值需要知道產品的抽象類，其他的實現類都不用關心，符合迪米特法則，我不需要的就不要去交流；也符合依賴倒置原則，只依賴產品類的抽象；當然也符合里氏替換原則，使用產品子類替換產品父類，沒問題！ 8.3.2 工廠方法模式的使用場景 首先，工廠方法模式是new一個對象的替代品，所以在所有需要生成對象的地方都可以使用，但是需要慎重地考慮是否要增加一個工廠類進行管理，增加代碼的復雜度。 其次，需要靈活的、可擴展的框架時，可以考慮采用工廠方法模式。萬物皆對象，那萬物也就皆產品類，例如需要設計一個連接郵件服務器的框架，有三種網絡協議可供選擇：POP3、IMAP、HTTP，我們就可以把這三種連接方法作為產品類，定義一個接口如IConnectMail，然后定義對郵件的操作方法，用不同的方法實現三個具體的產品類（也就是連接方式）再定義一個工廠方法，按照不同的傳入條件，選擇不同的連接方式。如此設計，可以做到完美的擴展，如某些郵件服務器提供了WebService接口，很好，我們只要增加一個產品類就可以了。 再次，工廠方法模式可以用在異構項目中，例如通過WebService與一個非Java的項目交互，雖然WebService號稱是可以做到異構系統的同構化，但是在實際的開發中，還是會碰到很多問題，如類型問題、WSDL文件的支持問題，等等。從WSDL中產生的對象都認為是一個產品，然后由一個具體的工廠類進行管理，減少與外圍系統的耦合。 最后，可以使用在測試驅動開發的框架下。例如，測試一個類A，就需要把與類A有關聯關系的類B也同時產生出來，我們可以使用工廠方法模式把類B虛擬出來，避免類A與類B的耦合。目前由于JMock和EasyMock的誕生，該使用場景已經弱化了，讀者可以在遇到此種情況時直接考慮使用JMock或EasyMock。