浅谈策略模式在消息转发场景下的应用
背景 在上一篇文章中，我们介绍了如何设计一个消息中心，传送门 👉《如何设计一个消息中心》 有了承载这些消息的地方后，接下来的问题便是，这些消息从哪里来？ 通常对于一个内容型产品来说，在其互动体系中，为了增强消息的用户触达，增强用户的互动心智，在互动（评论、点赞等）行为发生后，会将互动消息推送至消息中心，然后根据不同的互动行为类型匹配不同的消息模版。 然而随着互动行为种类的增加（内容的点赞、评论的点赞……），不断的通过 if…else 来根据不同的消息类型生成不同的消息模版会使得业务代码愈发复杂，难以维护。 不仅如此，一旦需要增加一种新的互动消息时，需要对原有代码进行破坏性修改，违背了“开闭原则”。因此有必要对互动行为消息转发至消息中心这一场景进行抽象，让后续的维护者、建设者只需要关心某一特定的互动行为消息即可（我可不想未来被别人喷在 💩 山上拉 💩）。 策略模式 在说明具体的实现方案前，我们先介绍一个设计模式——策略模式。 策略模式，英文全称是 Strategy Design Pattern。在 GoF 的《设计模式》一书中，它是这样定义的： Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. 翻译成中文就是：定义一簇算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端（这里的客户端代指使用算法的代码）。 策略模式用来解耦策略的定义、创建、使用。实际上，一个完整的策略模式就是由这三个部分组成的。 策略类的定义比较简单，包含一个策略接口和一组实现这个接口的策略类。 策略的创建由工厂类来完成，封装策略创建的细节。 策略模式包含一组策略可选，客户端代码如何选择使用哪个策略，有两种确定方法：编译时静态确定和运行时动态确定。其中，“运行时动态确定”才是策略模式最典型的应用场景。 实现方案 在对策略模式有了基本的了解后，我们尝试在本节将其运用起来。 仔细分析了第一章的应用场景后我们发现其实实现链路并不复杂，整体流程如下图所示： 在本例中，根据不同的互动行为类型，我们将点赞消息和评论消息分成以下几类： 点赞类： 内容点赞 评论点赞 评论类： 内容评论 内容评论的回复 转发策略的定义 整个方案中最重要的一环是对转发策略的匹配，因此第一步我们要做的应该是定义一个策略。为了方便后续的扩展（未来可能会有多种转发策略），我们此处定义一个策略接口MsgTransmitStrategy。...