在整個系統中使用相同參數創建對象

Question

我有一個執行非常特定任務的對象。要創建該對象，需要一些參數。我在我的系統的某些部分創建了一個新實例。但是有問題。如果將來必須更改參數或參數會怎麼樣？我需要在任何地方改變它。然後我想：「好吧，也許我可以在課堂上把它的創作封裝起來，如果一些論據發生變化，我將需要在一個地方改變它！」。

它確實對我很有意義。真正的問題是，這個「包裝物」是否反對工廠？它的責任是「用特定參數創建一個新對象並返回」。消費者只會使用這個對象...

Answer 1

你是一個重構代碼，以避免重複，這本身可能會提高你的整體可維護性。

如果這段重構代碼創建對象，那麼，是的，它是一個工廠。你稱之爲真的並不重要 - 你現在擁有的代碼是否更好的結構化？那就做吧！

但是，鑑於它是一個工廠研究工廠的經典設計模式，並且理解什麼導致人們使用這種模式的更復雜的形式。決定是否有任何導致他們使用「聰明」工廠的力量。

Answer 2

您描述的問題是，當類的構造函數參數發生更改時，您的類的所有客戶端都必須更改。引入工廠可能有助於防止重新編譯客戶端。但是這真的能解決問題嗎？如果您修改要使用另一個參數構造的類，該參數必須在某處確定，可能是在啓動構造的客戶端的上下文中。工廠班級應該如何知道？客戶是否必須將任何環境信息傳遞給工廠？

構建對象需要什麼參數？客戶是否提供了它們，或者事先是否可以創建對象，然後像注入工廠一樣注入客戶端（因爲我理解您的問題，後者似乎是這種情況）？考慮使用DI framework。這往往會使工廠過時。

你爲什麼害怕你的課程可能會改變？難道你的班級做得太多了嗎？注意Single Responsibility Principle。在你的情況下，Open/Closed Principle是一個有趣的研究。

據我所知，工廠不一定解決你描述的問題。工廠負責從客戶端創建對象，因此客戶端不必知道對象的具體類型。只要防止簽名保持穩定，也可以通過將參數包裝在單個對象中來完成。這也是衆所周知的refactoring pattern。但它也不能解決新參數來自何處的問題。