生成器模式VS我的執行

Question

我不得不建立一個日誌dll程序集，它將使用大量的可選參數，其中大約20個參數。它是用C＃編寫的。

我最終做的是讓我的日誌類接受類型爲「log」的對象。這個「log」類包含了所有需要的參數以及獲取/設置它們的相應屬性。 所有參數當然都是先用默認值啓動的。

一旦將「log」對象傳遞給我的主要日誌記錄類，它就會從該「日誌」對象中提取值並執行打印到文件。

我的問題是 - 我現在應該將其更改爲生成器模式？ （我剛剛學習 - 「Effective Java 2nd edition」一書）。

我可以看到這種模式對於調用具有十億個參數的Ctr/Methods的優點，但我也認爲傳入一個包含所有參數的新對象並不差。

你能解釋一下，如果我真的應該改變我的設計，爲什麼？

由於這是一個設計問題，我沒有提供任何代碼輸入。如果我需要發佈一些代碼，請告訴我。

Answer 1

使用設計模式沒有強制性規則。但如果應用於正確的用例，它會使生活更簡單。

你絕對可以在你的案例中使用Builder模式。這裏有一些指導原則：

1. 首先決定有多少個Log對象的屬性是強制性的（比如x數），以及有多少個屬性是可選的（y）。

2.從日誌對象中刪除y屬性，並通過「add」方法將它放入Builder類。

1. 如果x < 6，取出x在日誌類屬性，把它們放在你的生成器類的構造函數。現在你可以擺脫Log類本身。

2. 否則，如果x> = 6，請將它們保留在日誌類中，並在Builder類的構造函數中傳遞該類。這也被稱爲「傳送對象」。

您可以根據需要更改決定編號6。通常，包含6個或更多參數的構造函數變得不易讀。

Answer 2

你有許多參數的構造函數，其中很多參數都是相同的類型？去建設者。

你有很多構造函數，它們之間的差別很小？去建設者。

您是否有一個類初始化，其中一個構造函數調用另一個構造函數，遵循鏈式結構？去建設者。

否則，做你自己的事情。