对于「对象分散」的问题来说，创建型的设计模式基本能解决这个问题，对应到这里，可以直接使用工厂方法！

使用了工厂方法后，构建代码被限制在了工厂方法内部，当策略对象的构造逻辑调整时，我们只需要调整对应的工厂方法就可以了。

依赖倒置

现在「调用层」只和「实现层」的StategyFactoryImpl有直接的关系，解决了「对象分散」的问题。但是即使只依赖一个类，调用层依然和实现层是强依赖关系。

该如何解决这个问题呢？我们需要依赖倒置。一般方法是使用接口，例如这里的「逻辑层」和「实现层」就是通过接口来实现了依赖倒置：「逻辑层」并不强依赖于「实现层」的任何一个类。箭头方向都是从「实现层」指向「逻辑层」的，所以称为依赖倒置

但是对于「调用层」来说，此方法并不适用，因为它需要实例化具体的对象。那我们该如何处理呢？

相信你已经想到了，就是我们一直在用的IOC！通过注入的方式，使得依赖倒置！我们可以直接替换掉工厂方法。

可以看到，通过依赖注入，使得「调用层」和「实现层」都依赖于「逻辑层」。由于「逻辑层」也是相对较稳定的，所以「调用层」也就不会频繁的变化，现在需要变化的只有「实现层」了。

逻辑显化

最后一个区别就是设计模式使得逻辑显化。什么意思呢？

当你使用ifelse的时候，实际上你需要深入到具体的ifelse代码，你才能知道它的具体逻辑是什么。

对于使用设计模式的代码来说，我们回过头来看上面的架构图，从这张图你就能看出来对应的逻辑了：

• 由StrategyFactory实例化所有Strategy的实现
• Client通过StrategyFactory获取Strategy实例，并将其设置到Context中
• 由Context委托给具体的Strategy来执行具体的逻辑

至于具体的Strategy逻辑是什么样子的，你可以通过类名或方法名来将其显化出来！

总结

本文通过将使用设计模式的代码和不使用设计模式的代码分别放到架构中，对比设计模式对架构所产生的影响:

• 划分边界
• 解耦
• 独立进化
• 对象聚集
• 依赖倒置
• 逻辑显化

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!