Chain of Responsibility设计模式有哪些替代方案？

Question

我正在为业务线应用程序构建邮件模块.情况是,当发送邮件以响应某些输入时,应将它们分组,以便用户不会收到具有不同项目的多个连续邮件,而只包含包含所有项目的邮件.此外,邮件应按特定类型分组,这取决于创建邮件通知的输入类型,我有输入列表,每个都有其特定的分组类型,例如:

层次结构:员工有进程有请求有活动

活动1: 通过员工(因此接收者只需一封邮件即可获得他拥有此活动类型的流程的所有通知)

活动2: 按流程(接收方将获得有关此流程的所有请求的所有通知的一组,以及此活动类型)

活动3: 按要求(此请求的活动将被分组)

活动4: 按活动(每项活动将以单独的邮件发送)

这种分组会不断变化.

您可能会认为,为了做到这一点,应该立即进行输入,以便同时生成邮件并进行分组,否则系统将如何知道何时等待其他输入以及何时只发送单独的邮件？答案是两个,所以我正在做的是设置一个计时器,使邮件服务每5分钟运行一次,一些即时邮件可能会延迟几分钟,但这是一个负担得起的权衡.

所以我选择使用这个责任链设计模式,这里是结构:

所以我有两个接口IGroupingType定义每个类型应该如何,并有两个方法CalculateGrouping()::确定这是否是活动的分组.GroupEmailsToSend():如果这是分组,请获取邮件列表.

接口IGroupingHandler是将调用每个分组类型的服务类,GetGroupingResult()只调用IGroupingType具体实现上的2个方法,首先CalculateGrouping()获取正确的分组,当它找到它时,调用GroupEmailsToSend().此接口还为每个分组注册链中的下一个节点.

分组枚举仅用于返回分组计算的结果.

然后还有EndOfChainSendingGrouping类,如果没有找到分组,我将立即发送邮件.

基本上,我只需要对这种结构提出一些建议,因为我对这种模式有点新意,是否有任何陷阱？有什么我可以改进的吗？或者有更好的方法来实现这一目标吗？

提前致谢..

Answer 1

我认为链接听起来不错，而且似乎是最适合这里的。最终，装饰器模式可用于过滤接收者列表。