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

Question

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

层次结构：员工 流程 请求 活动

活动1： 按员工（因此接收方只需一封邮件即可获得他拥有此活动类型的流程的所有通知）

活动2： 按流程（接收方将获得有关此流程和此活动类型的所有请求的所有通知的一组）

活动3： 按要求（此请求的活动将被分组）

活动4： 按活动（每项活动将以单独的邮件发送）

这种分组会不断变化。

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

所以我选择使用这个Chain of Responsability Design Pattern，这是结构：

所以我有两个接口 IGroupingType ，它定义了每种类型的方式，并且有两种方法：CalculateGrouping()：确定这是否是活动的分组。 GroupEmailsToSend()：如果这是分组，请获取邮件列表。

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

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

然后还有 EndOfChainSendingGrouping 类，如果没有找到分组，我会马上发送邮件。

基本上我只是需要一些关于这种结构的建议，因为我对这种模式有点新意，它有任何陷阱吗？有什么我可以改进的吗？还是有更好的方法来实现这个目标？

提前致谢..

Answer 1

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