我目前正在建立一个系统,该系统的实体将具有声誉等等。
我将提供一项服务,检查已触发的某些规则,并在触发时执行某些逻辑。
以前我只用一个Enum来做这个,因为我只需要存储一个id和一个描述。
public enum ShoppingCratCalculation
{
PartialCalculation = 1,
CompleteCalculation =2
}
但在这种情况下,我想在一个地方传递更多信息,例如修改声誉。
我实质上是在为系统中的每条规则询问哪种数据结构最适合存储此信息。
1. Description = string ("User forgot to write a review")
2. DB id = int (23)
3. Rep score modification = int (-5)
也许是一个小班(Rule
),将这些作为属性,然后只是一个list<Rule>
?
有没有人对这种结构有任何最佳实践建议?
答案 0 :(得分:1)
您可能想看一些production systems。这些允许您通过执行定义的操作来处理规则并对操作做出反应。
答案 1 :(得分:1)
我可能会使用类来存储规则数据,但用于存储规则数据的数据结构实际上取决于规则的组织方式。你说它就像SO,但通常将动作映射到声誉上。从您的示例中,听起来好像您将某个操作的品质映射到声誉。在这种情况下,使用相同类型的系统可能不合适。例如,你真的想要一个负面评分行动的可能性 - 所以允许这样做,但也许你不这样做。毕竟,听起来你的目标是出售东西 - 你可能想要考虑一个人在购买东西时给予负面声誉的影响。
话虽如此,这里有一些我会考虑的事情。如果结构是扁平的并且在任何给定时间只能应用一个规则或每个规则是独立的,那么由规则标识符(可能是枚举)键入的字典可能是合适的。如果可以应用多个规则并且它们进行交互,那么您可能希望将它们存储在集合中,并使用所有匹配规则中的Decorator模式构建复合规则。例如,使用经过身份验证的帐户进行购买并撰写评论可能会比使用匿名帐户撰写评论更具声誉。如果规则是分层的,即有一些优先权,那么带有中止链的选项的过滤器链可能更合适。