創建者和產品

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

 

 

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

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

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

 

定義工廠方法模式

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

工廠方法模式能夠封裝具體類型的實例化。看下面的類圖，抽象的Creator提供了一個創建對象的方法的接口，也稱為“工廠方法”。在抽象的Creator中，任何其他實現的方法，都可能使用到這個工廠方法所制造出來的產品，但只有子類真正實現這個工廠方法并創建產品。

 

對象依賴

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

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;
        }
    }
}

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

 

依賴倒置原則

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

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

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

原則的應用

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

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

 

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

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

在依賴倒置原則中的倒置指的是和一般OO設計的思考方式相反。看看上面的圖，你會注意到低層組件現在竟然依賴高層的抽象。同樣地，高層組件現在也依賴相同的抽象。以前繪制的依賴圖都是自上而下的，現在卻倒置了，而且高層和低層模塊現在都依賴這個抽象。

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

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

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

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

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