尋找比賽的設計模式

Question

在使用設計模式構建代碼時需要幫助。

所以我在服務類中只有一個看起來像這樣的方法。 構造函數將json文件加載到Option類實例的List<Option>中。 最后，當調用服務方法時，它會執行一些邏輯以根據參數值查找Option匹配項，並返回帶有已配置的“選項”的“工具”類的新實例。

public Tool BestOptionFinderService.FindBestMatch(string value 1, int value2, int value3, .. bool value20, etc...) {..}

我不確定“服務”類相對於“工廠”還是其他類是否正確。 對於您如何設計此問題或類似代碼的想法和建議，我將不勝感激。

Answer 1

我想說，只有約20個參數的單一方法本身很糟糕，甚至沒有考慮OOP模式。 讓我們嘗試做的更好； 更重要的是，讓我們嘗試不要重新發明輪子。

重要但顯而易見的觀察：無論匹配邏輯是什么，任何對象要么匹配要么不匹配，並且永遠不會兩者都匹配。 因此，堅持使用布爾代數和諸如predicate: t -> bool這樣的簽名是有意義的predicate: t -> bool或bool Predicate<T>(T obj) 。 關於謂詞，我們知道的另一件事是，一個謂詞可以輕松地將任意兩個簡化為一個謂詞：可以通過多種方式來實現，但是顯然您對and或&&運算符感興趣。

因此，您可能有二十個不同的簡單，清晰，自我描述的謂詞，而不是具有20個參數，隨后將它們“簡化”為一個實例。 Linq.Aggregate()可以幫助您不僅美化您的代碼，還可以使其並行（如有必要）。 然后，您可以將輸入映射到足夠數量的標志（由您決定是否需要更多或不需要），這些標志代表正在檢查的特定對象的“適合性”。

這樣的方法確實會更好，因為：

1）您堅持使用著名的布爾代數，

1.A）實際上在各種操作（包括and下形成一個單面體

1.B）可以輕松分布在任何計算集群上

1.C）緊湊，富有表現力，自我解釋。

2）您的代碼講述了更多故事： 簡單謂詞易於讀取，維護，單元測試和重構，而20參數方法絕不會這樣。

3）您清楚地將原始圖元與合成物分離-由一些已知的原始圖元構建的更復雜的結構。 這就是數學發展的方式，因此是唯一已知的可靠方法，經過數千年的實踐證明，它可以解決復雜性並且不會在某個時候被它束縛。

4）還有更多優點，但是我討厭打字;）