复杂决策系统的正确设计模式是什么
我正在设计一个调用复杂逻辑的决策系统，可能我需要使用大量嵌套的 if/else 语句，
我想看看是否有更好的设计模式可以帮助我简化结构并为以后的改进提供一定的可扩展性。
该项目的问题可以简化为：
我们现在需要对一个请求做出决定，该请求具有 3 种属性，甚至可能更多。它们是 PricePolicy（合同/批发/零售/折扣）、RequestType（买/卖）和 ProductType（时装/家居/玩具）。
每个决策都是基于请求的所有 3 个属性，因为价格政策的类型将来可能会发生变化，并且更多属性将添加到决策过程中。
所以我试图避免制作一个大的 switch 语句，这对于将来的扩展来说是丑陋且困难的。如：
switch(ProductType) {
case Fashion:
switch(PricePolicy) {
case Contract:
if(Request == Buy) {
// making a decision.
} else {
}
}
}
}
请分享您的想法和建议，谢谢。
干杯， 鲍勃
I am working on the design of a decision making system that invokes complicate logic, potentially I will need to use a lot of nested if/else statements,
I want to see if is there a better design patter than can help me to simplify the structure of the system and provide a certain extensibility for future improvement.
The problem of the project can be simpified as:
We are now need to making a decision for a request, which has 3 type of properties, and potentially more. They are PricePolicy (Contract/WholeSale/Retail/Discount), RequestType (Buy/Sell) and ProductType (Fashion/Household/Toys).
Each decision making is based on all the 3 properties of the request, because the type of price policy may change in the future, and more properties will be added to the decision making process.
So I am trying to avoid the making a large switch statement, which is ugly and deficult for future extensions. Such as:
switch(ProductType) {
case Fashion:
switch(PricePolicy) {
case Contract:
if(Request == Buy) {
// making a decision.
} else {
}
}
}
}
Please share you idea and suggestions Thank you.
Cheers,
Bob
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
也许您想要一个 Rete 规则引擎。尝试流口水。
或者数据驱动的决策表。
如果您想要一个类解决方案，请考虑多态性。将所有这些 if/then/else 情况替换为 Strategy 或 Visitor 等类。
关键是接口稳定。如果您可以保持稳定并更改底层的实现，那么您就成功了。
Maybe you want a Rete rules engine. Try Drools.
Or a data-driven decision table.
If you want a class solution, think polymorphism. Replace all those if/then/else cases with classes like Strategy or Visitor.
The key is stable interfaces. If you can keep that stable, and change the implementations underneath, you've got it.
使用 n 维数组，并以这种方式查找/查询/修改您的决策。
Use a n-dimensional array, and lookup/query/modify your decisions that way.
正如 ziplin 所建议的，如果每个组合都有一个决策（即不是决策的“稀疏”分布 - 我认为这是正确的术语），我会考虑使用 3d 数组。这需要您能够将决策逻辑封装在可以存储在数组中的表达式中。对于稀疏分布，可以以类似的方式使用邻接表。
As ziplin suggested, I would consider a 3d array if there is a decision for each combination (ie. not a 'sparse' distribution of decisions - I think that's the correct term). This would require that you are able to encapsulate the decision logic in an expression which can be stored within the array. With a sparse distribution, an adjacency list could be used in a similar fashion.