寻找匹配的设计模式答案

【问题标题】：Design patterns for finding a match寻找匹配的设计模式
【发布时间】：2018-03-24 16:36:25
【问题描述】：

在使用设计模式构建我的代码时需要帮助。

所以我在服务类中有一个方法，看起来像这样。构造函数将 json 文件加载到 List<Option> 的 Option 类实例中。最后，当调用服务方法时，它会根据参数值执行一些逻辑来查找Option 匹配项，并返回一个带有配置的“选项”的“工具”类的新实例。

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

我不确定我的“服务”类与“工厂”或其他东西相比是否正确。对于如何针对此问题或类似问题设计代码，我将不胜感激您的想法和建议。

【问题讨论】：

用in参数解释FindBestMatch的逻辑：value1,value2,....
所以我在服务类中有一个看起来像这样的方法 - 你忘记包含方法的代码
它只是循环通过 List<Option> 并找到与传递的参数值组合最接近的匹配项。

标签： c# design-patterns

【解决方案1】：

我会说，拥有约 20 个参数的单一方法本身就很糟糕，甚至没有考虑 OOP 模式。让我们努力做得更好；不仅如此，让我们尽量不要重新发明轮子。

重要但显而易见的观察：无论一个人有什么匹配逻辑，任何对象要么匹配要么不匹配，而且永远不会同时匹配。因此，坚持使用布尔代数和predicate: t -> bool 或bool Predicate<T>(T obj) 之类的签名是有意义的。关于谓词，我们知道的另一件事是，可以轻松地将任意两个简化为一个：有不同的方法可以做到这一点，但是您显然对 and 或 && 运算符感兴趣。

因此，您可以有 20 个不同的简单、清晰、自描述谓词，而不是 20 个参数，然后将其“简化”为一个实例。 Linq.Aggregate() 不仅可以帮助您美化您的代码，还可以使其并行化（如有必要）。然后，您可以将您的输入映射到足够（由您决定是否需要更多或不需要）数量的标志，代表您正在检查的特定对象的“适合度”。

这种方法确实会更好，因为：

1) 你坚持著名的布尔代数，

1.A) 实际上，在各种操作下形成一个monoid，包括and，然后又形成了它

1.B) 可轻松分布在任何计算集群上

1.C) 紧凑、富有表现力、不言自明。

2) 您的代码讲述了更多故事：简单谓词易于阅读、维护、单元测试和重构，而 20 参数的方法则不然。

3) 你清楚地将你的基元与组合物分开——更复杂的结构，由一些已知的基元构成。这就是数学的发展方式，因此是唯一已知的可靠的、经过数千年证明的方法来解决复杂性并且不会在某些时候被它所奴役。

4) 还有更多优点，但是我打字累了；)

【讨论】：