bug_null的博客

7. 重构实例-消息发送-使用策略进行重构-枚举方式由于这是一个长文，分成了好几章来介绍如何重构。原始代码及准备职责独立去除static关键字接口添加转换方法方法合并使用策略进行重构-Map方式使用策略进行重构-枚举方式经过上一次的重构我想你基本理解了使用map的策略模式，我们再来看使用策略模式的另一种实现list7.1 重构步骤这个还是规矩检查单元测试。使用枚举将类型与实例相绑定。进行策略的实现。执行单元测试。7.2 检查单元测试这个单元测试没有变化，可跳过7.

6 重构实例-消息发送-使用策略进行重构-Map方式由于这是一个长文，分成了好几章来介绍如何重构。原始代码及准备职责独立去除static关键字接口添加转换方法方法合并使用策略进行重构-Map方式使用策略进行重构-枚举方式6.1 问题分析经过前两轮的重构之后，已经提取了抽象接口，并将其static去掉。还为消息发送接口添加了转换方法,并对代码进行了方法的合并操作。经过这几轮的修改，代码已经看起来整洁、清晰了许多。但是还存在一个问题，那就是每当要添加一个新的渠道的时候，就得改动Mess

5.重构实例-消息发送-方法合并由于这是一个长文，分成了好几章来介绍如何重构。原始代码及准备职责独立去除static关键字接口添加转换方法方法合并使用策略进行重构-Map方式使用策略进行重构-枚举方式经过前两轮的重构之后，已经提取了抽象接口，并将其static去掉。还为消息发送接口添加了转换方法。经过这几轮的修改，代码已经看起来整洁、清晰了许多。那还有槽点吗？public class MessageSender { public void sendMessage(Stri

4.重构实例-消息发送-添加转换方法由于这是一个长文，分成了好几章来介绍如何重构。原始代码及准备职责独立去除static关键字接口添加转换方法方法合并使用策略进行重构-Map方式使用策略进行重构-枚举方式经过前两轮的重构之后，已经提取了抽象接口，并将其static去掉。经过这两轮重构后，有没有什么设计是不合理的呢？再次回收代码中:public class MessageSender { public void sendMessage(String msgType, Messag

3. 重构实例-消息发送-去除static关键字由于这是一个长文，分成了好几章来介绍如何重构。原始代码及准备职责独立去除static关键字接口添加转换方法方法合并使用策略进行重构-Map方式使用策略进行重构-枚举方式现在来思考下NotifySendUtils中直接调用发送代码的做法，是否合理呢？或者说在我们原来的代码中，增加了一层调用，有必要吗？我觉得这个问题得分场景来看，如果是一个大系统中的一部分，NotifySendUtils被几十甚至上百的文件引用，那么这样的改动是相当合理的，

2. 重构-策略模式-职责独立由于这是一个长文，分成了好几章来介绍如何重构。原始代码及准备职责独立去除static关键字接口添加转换方法方法合并使用策略进行重构-Map方式使用策略进行重构-枚举方式现在来分析下代码的问题先从入口MessageSender开始吧，这个类第一眼看上去，觉得很简单吧，就是按类型判断下，执行NotifySendUtils类中的发送逻辑代码。这样子看这个类没有什么大的问题么，再说NotifySendUtils吧，它封装了各种发送渠道的调用方法，还做成了静态方

1. 重构-策略模式-原始代码及准备由于这是一个长文，分成了好几章来介绍如何重构。原始代码及准备职责独立去除static关键字接口添加转换方法方法合并使用策略进行重构-Map方式使用策略进行重构-枚举方式1.1 原始代码这是来自于我所经历的项目中一个消息发送的程序，调用者告诉发送程序：类型、接收者及消息的内容，发送程序会根据发送的类型调用不同的发送程序，将待发送的消息发送出去。 目前已知的发送渠道包括：短信、email、微信、钉钉、企业微信， 由于短信、email、微信、钉钉、企业