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