工廠方法中的繼承模式與抽象工廠模式中的組合

Question

我只是通過工廠方法模式和抽象工廠方法模式的維基頁面。

從Head First設計模式，我得到這個

工廠方法模式使用繼承，抽象工廠模式使用 組成。抽象工廠模式也可以像Factory Method Pattern一樣執行，它使客戶端與具體類型分離，但以不同的方式。

在分析wiki示例之後，我實際上找不到示例中的組合。這兩種模式都使用繼承。

工廠方法模式

抽象工廠模式

這裏是我的問題。

1. 工廠方法模式總是隻有一個抽象產品繼承樹不像抽象工廠方法模式？
2. 哪裏可以使用或編程方式的組成？如果它只是具有main方法的Client，則Factory Method Pattern也使用Composition。代碼片段的例子將清除這個概念。
3. 我對樣本草圖中的這些模式的解釋是否正確？

Answer 1

是的，正如「Fuhrmanator」指出的那樣，它看起來是重複的。所提到的問題答案對這兩種模式提供了很好的解釋。簡而言之，GOF設計模式目錄會談到三種與「工廠」術語相關的模式。所有三個都是創作模式。大多數人在使用術語「工廠模式」時使用靜態工廠實施。

靜態工廠在本質上是

AbstractProduct getProduct(key){ 
    if (key == ...) return new ConcreteProduct1(); 
    ... so on. 
} 

廠方法的一種方法包封的具體類的創建被維持爲鉤一個抽象方法，以延緩混凝土產品的實例化的方便的方法。當我們在編寫業務邏輯的框架編寫時，這是非常有用的，但我們不希望假設客戶端開發人員將在以後編寫的具體類（此邏輯適用於此類）的任何內容。 （未重複的UML圖圖案的在這裏）

抽象工廠模式是工廠方法，在這裏我們需要限制其可實例化並使用，但完整的風味變化（其中我們將產品的類型的更一般的情況在整個應用程序生命中不會一直在不同的口味之間進行切換）。

例如抽象ShapeFactory可能創造3種形狀，如圓形，正方形和長方形提供接口，而混凝土工廠FilledShapeFactory和HollowShapeFactory將它們必然會填補，這三種形狀的空心版本（具體工廠不能自由決定新形狀或放下任何形狀）。

如果各種形狀（產品）因強制更改界面和影響客戶端而發生更改，則無法使用此模式。

風味變化的原因可能是由於父母環境，操作系統或任何其他嚴重影響的參數。