意：問題在帖子末尾。我已經閱讀了有關Abstract Factory vs Factory Method的其他stackoverflow線程。我了解每種模式的意圖。但是，我對該定義不清楚。Factory Method定義了一個用于創建對象的接口，但是讓子類決定要實例化的對象。工廠方法允許類將實例化延遲到子類。相比之下，抽象工廠提供了一個接口，用于創建相關或相關對象的族，而無需指定其具體類。- 約翰·費米內拉該抽象工廠看起來非常相似的工廠方法。我畫了一些UML類來說明我的觀點。注意：該圖來自www.yuml.com，因此它們的方向不完全正確。但它是免費的服務:)。這些圖可能并不完美。我仍在學習GoF設計模式。工廠方法：抽象工廠（僅1個成員）：抽象工廠（更多成員）：問題：如果抽象工廠只有一個創建者和一個產品，那么它仍然是抽象工廠模式嗎？（用于創建家族的界面）可以從接口創建Factory Method具體創建器，還是必須從類創建它？（類將實例化延遲到子類）如果抽象工廠只能有一個創建者和一個產品，那么抽象工廠和工廠方法之間的唯一區別是前者的創建者是一個接口，后者的創建者是一個類嗎？
3 回答
翻翻過去那場雪
TA貢獻2065條經驗 獲得超14個贊
看來，OP的（優秀）問題列表已被忽略。當前的答案僅提供了經過重新定義的定義。因此，我將嘗試簡潔地解決原始問題。
如果抽象工廠只有一個創建者和一個產品，那么它仍然是抽象工廠模式嗎？（用于創建家族的界面）
沒有。抽象工廠必須創建多個產品才能制作“相關產品系列”。規范的GoF示例創建ScrollBar()和Window()。優點（和目的）是，抽象工廠可以在其多個產品中強制使用一個公共主題。
可以從接口創建Factory Method具體創建器，還是必須從類創建它？（類將實例化延遲到子類）
首先，我們必須注意，GoF編寫本書時既沒有Java也沒有C＃。術語接口的GoF使用與特定語言引入的接口類型無關。因此，可以從任何API創建具體的創建者。模式中的重點是API使用了自己的Factory方法，因此只有一個方法的接口不能是Factory方法，而只能是Abstract Factory。
如果抽象工廠只能有一個創建者和一個產品，那么抽象工廠和 工廠方法之間的唯一區別是前者的創建者是一個接口，后者的創建者是一個類嗎？
按照上述答案，該問題不再有效；但是，如果您認為抽象工廠和工廠方法之間的唯一區別是創建的產品數量，請考慮客戶如何使用這些模式中的每一個。通常將抽象工廠注入其客戶端，并通過組合/委托進行調用。工廠方法必須被繼承。因此，一切都回到了舊的組合與繼承之爭。
但是這些答案提出了第四個問題！
由于只有一個方法的接口不能是工廠方法，而只能是抽象工廠，所以我們怎么稱呼只有一個方法的創建接口？
如果該方法是靜態的，則通常稱為“ 靜態工廠”。如果該方法是非靜態的，則通常稱為簡單工廠。這些都不是GoF模式，但是在實踐中它們更常用！
- 3 回答
- 0 關注
- 732 瀏覽
添加回答
舉報
0/150
提交
取消