工廠方法模式
工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性，使得它可以被子類繼承。這樣在簡單工廠模式裏集中在工廠方法上的壓力可以由工廠方法模式裏不同的工廠子類來分擔。
你應該大致猜出了工廠方法模式的結構，來看下它的組成：
1) 抽象工廠角色： 這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java 中它由抽象類或者接口來實現。
2) 具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以創建對應的具體產品的對象。
3) 抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在 java 中一般有抽象類或者接口來實現。
4) 具體產品角色：具體工廠角色所創建的對象就是此角色的實例。在 java 中由具體的類來實現。
工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的“上帝類”。正如上面所說，這樣便分擔了對象承受的壓力；而且這樣使得結構變得靈活起來——當有新的產品（即暴發戶的汽車）產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生
成，那麼就可以被客戶使用，而不必去修改任何已有的代碼。可以看出工廠角色的結構也是符合開閉原則的！
我們還是老規矩，使用一個完整的例子來看看工廠模式各個角色之間是如何來協調的。話說暴發戶生意越做越大，自己的愛車也越來越多。這可苦了那位司機師傅了，什麼車它都要記得，維護，都要經過他來使用！於是暴發戶同情他說：看你跟我這麼多年的份上，以後你不用這麼辛苦了，我給你分配幾個人手，你只管管好他們就行了！於是，工廠方法模式的管理出現了。代碼如下：
//抽象產品角色，具體產品角色與簡單工廠模式類似
- //抽象產品角色
- public interface Car{
- public void drive();
- }
- //具體產品角色
- public class Benz implements Car{
- public void drive() {
- System.out.println("Driving Benz ");
- }
- }
- public class Bmw implements Car{
- public void drive() {
- System.out.println("Driving Bmw ");
- }
- }
- //抽象工廠角色
- public interface Driver{
- public Car driverCar();
- }
- public class BenzDriver implements Driver{
- public Car driverCar(){
- return new Benz();
- }
- }
- public class BmwDriver implements Driver{
- public Car driverCar() {
- return new Bmw();
- }
- }
- //應該和具體產品形成對應關係...
- //有請暴發戶先生
- public class Magnate
- {
- public static void main(String[] args)
- {
- try{
- Driver driver = new BenzDriver();
- Car car = driver.driverCar();
- car.drive();
- }
- ……
- }
- }
可以看出工廠方法的加入，使得對象的數量成倍增長。當產品種類非常多時，會出現大量的與之對應的工廠對象，這不是我們所希望的。因爲如果不能避免這種情況，可以考慮使用簡單工廠模式與工廠方法模式相結合的方式來減少工廠類：即對於產品樹上類似的種類（一般是樹的葉子中互爲兄弟的）使用簡單工廠模式來實現。
五、小結
工廠方法模式彷彿已經很完美的對對象的創建進行了包裝，使得客戶程序中僅僅處理抽象產品角色提供的接口。那我們是否一定要在代碼中遍佈工廠呢？大可不必。也許在下面情況下你可以考慮使用工廠方法模式：
1) 當客戶程序不需要知道要使用對象的創建過程。
2) 客戶程序使用的對象存在變動的可能，或者根本就不知道使用哪一個具體的對象。
簡單工廠模式與工廠方法模式真正的避免了代碼的改動了？沒有。在簡單工廠模式中，新產品的加入要修改工廠角色中的判斷語句；而在工廠方法模式中，要麼將判斷邏輯留在抽象工廠角色中，要麼在客戶程序中將具體工廠角色寫死（就象上面的例子一樣）。而且產品
對象創建條件的改變必然會引起工廠角色的修改。
面對這種情況，Java 的反射機制與配置文件的巧妙結合突破了限制——這在Spring 中完美的體現了出來。