我们有一个方法，它包含一个复杂的业务逻辑来评估许多条件，到最后这个方法应该返回一个类型为Rule的对象。
该方法是使用大量if else和嵌套的if else来实现的。在我们的情况下，The execution order is VERY IMPORTANT。
我们想使用设计模式重构这个方法。我在stackoverflow上看到很多人在谈论**Chain of Responsibility，Command，Factory和State Pattern**，但我不确定这个用例的正确模式。
1条答案
按热度按时间rdrgkggo1#
我最近也在做类似的事情，我发现解决方案介于Visitor和Chain of Responsibility模式之间，两者都不适合。
我能够编写一个对象列表，这些对象必须有机会执行一些业务逻辑并返回最终结果。每个对象都有一组唯一的依赖项。我使用一个IoC容器来使用公共接口解析这些对象。我能够通过使用表示序列的属性并按此对列表进行排序来对这些对象进行排序。
我遇到的问题是，每个对象需要不同的运行时数据。访问者和责任链模式通常使用一致的方法签名。我发现我需要一个“上下文”对象参数来覆盖每个逻辑对象可能需要的所有潜在属性。这是当我知道它确实是正确的方法，因为许多对象正在传递他们不感兴趣的数据。
由于时间限制，我恢复到类似于Template Method模式的东西，但实际上只是一个Transaction Script，其中方法按照定义的顺序调用每个对象。对象通过IoC解析，并具有支持自动化测试的某些抽象的接口。这是可以的，但在测试中变得棘手，因为它需要比它应该的更多的模拟。
最终，我认为这样的事情没有一个整洁的，“经典的”设计模式来解决它。我认为你正在寻找将业务逻辑重构为单独的类，然后通过迭代器或管道调用它们-如果你重新定义你的问题，突出设计问题，而不是试图找到一个适合的模式，你可能会得到一个更好的答案。