java中工廠方法模式的示例分析

創(chuàng)建者和產(chǎn)品

所有工廠模式都用來封裝對象的創(chuàng)建。工廠方法模式（Factory Method Pattern）通過讓子類決定該創(chuàng)建的對象是什么，來達到將對象創(chuàng)建的過程封裝的目的。讓我們來看看這些類圖，以了解有哪些組成元素：

 

 

另一個觀點：平行的類層級

上面已經(jīng)看到，將一個orderPizza()方法和一個工廠方法聯(lián)合起來，就可以成為一個框架。除此之外，工廠方法將生產(chǎn)知識封裝進各個創(chuàng)建者，這樣的做法，也可以被視為是一個框架。

讓我們來看看這兩個平行的類層級，并認清它們的關(guān)系：

 

定義工廠方法模式

工廠方法模式定義了一個創(chuàng)建對象的接口，但由子類決定要實例化的類是哪一個。工廠方法讓類把實例化推遲到子類。

工廠方法模式能夠封裝具體類型的實例化?？聪旅娴念悎D，抽象的Creator提供了一個創(chuàng)建對象的方法的接口，也稱為“工廠方法”。在抽象的Creator中，任何其他實現(xiàn)的方法，都可能使用到這個工廠方法所制造出來的產(chǎn)品，但只有子類真正實現(xiàn)這個工廠方法并創(chuàng)建產(chǎn)品。

 

對象依賴

假設(shè)你從未聽過工廠模式，那么按照之前的，如果要開一家紐約和芝加哥的披薩店，并且有各種風(fēng)味的披薩對象，你是否可以想象這個類所以來的具體披薩對象有幾種呢？如果又增加了一種加州風(fēng)味，又會有依賴多少個對象呢？不妨讓你看看：

public lass DependentPizzaStore {
    public Pizza createPizza(String style, String type) {
        Pizza pizza = null;
        if(style.equals("NY")) {
            if(type.equals("cheese")) {
                pizza = new NYStyleCheesePizza();
            } else if(tpye.equals("clam")) {
                pizza = new NYStyleClamPizza();
            } else if(type.equals("pepperoni")) {
                pizza = new NYStylePrpperoniPizza();
            }
        } else if(style.equals("Chicago")) {
            if(type.equals("cheese")) {
                pizza = new ChicagoStyleCheesePizza();
            } else if(tpye.equals("clam")) {
                pizza = new ChicagoStyleClamPizza();
            } else if(type.equals("pepperoni")) {
                pizza = new ChicagoStylePrpperoniPizza();
            }
        } else {
            System.out.println("Error: invalid type of pizza");
            return null;
        }
    }
}

當(dāng)你直接實例化一個對象時，就是在依賴它的具體類。如果把這個版本的披薩店和它的依賴對象畫成一張畫，看起來是這樣的：

 

依賴倒置原則

從上面看到了，我們代碼里減少對于具體類的依賴是一件好事。事實上，有一個OO設(shè)計原則就正式闡明了這一點；這個原則甚至還有一個又響亮又正式的名稱：“依賴倒置原則”。要依賴抽象，不要依賴具體類。

這個原則和“針對接口編程，不針對實現(xiàn)編程”類似，但是這個原則，更強調(diào)“抽象”。這個原則說明了：不能讓高層組件依賴低層組件，而且，不管高層或低層組件，“兩者”都應(yīng)該依賴于抽象。

所謂“高層”組件， 是是由其他低層組件定義行為的類。例如，PizzaStore是個高層組件，因為他的行為是由披薩定義的；PizzaStore創(chuàng)建所有不同的披薩對象，準(zhǔn)備、烘烤、切片、裝盒；而披薩本身屬于低層組件。PizzaStore依賴這些具體披薩類。

原則的應(yīng)用

非常依賴披薩店的主要問題在于：它依賴每個披薩類型。因為它是在自己的orderPizza()方法中，實例化這些具體類型的。

如何在orderPizza()方法中，將這些實例化對象的代碼獨立出來？我們都知道，工廠方法剛好派上用場了。應(yīng)用了工廠方法之后，類圖就改成了下面這個樣子：

 

在應(yīng)用工廠方法之后，你注意到了沒，高層組件（PizzaStore）和低層組件（也就是這些披薩）都依賴了Pizza抽象。想要遵循依賴倒置原則，工廠方法并非是唯一的技巧，但卻是最有威力的技巧之一了。

依賴倒置，究竟倒置在哪里？

在依賴倒置原則中的倒置指的是和一般OO設(shè)計的思考方式相反?？纯瓷厦娴膱D，你會注意到低層組件現(xiàn)在竟然依賴高層的抽象。同樣地，高層組件現(xiàn)在也依賴相同的抽象。以前繪制的依賴圖都是自上而下的，現(xiàn)在卻倒置了，而且高層和低層模塊現(xiàn)在都依賴這個抽象。

依賴倒置，還需要倒置你的思考方式。之前如果你需要設(shè)計一個披薩店，會從頂端開始，然后往下到具體類?，F(xiàn)在就需要倒置你的想法，別從頂端開始，而是從披薩開始，然后想到抽象化一個Pizza類。繼而想到必須要靠一個工廠來將這些類取出披薩店，不同的披薩類型都只能依賴一個抽象，同樣的披薩店也會依賴這個抽象。

就這樣，我們倒置了一個商店依賴具體類的設(shè)計，而且也倒置了你的思考方式。但是，也需要避免在OO設(shè)計中違反依賴倒置原則：

1. 變量不可以持有具體類的引用：如果使用new，就會持有具體類的引用。你可以改用工廠來避開這樣的做法

2. 不要讓類派生自具體類：如果派生自具體類，你就會依賴具體類。請派生自一個抽象（接口或抽象類）

3. 不要覆蓋基類中已實現(xiàn)的方法：如果覆蓋基類已實現(xiàn)的方法，那么你的基類就不是一個真正適合被繼承的抽象。基類中已實現(xiàn)的方法，應(yīng)該由所有的子類共享