首先，使用策略模式使得架构的边界与使用ifelse编码方式的架构的边界不同。策略模式将代码分成了三部分，这里称为：

• 调用层：将下层的业务逻辑组装起来，形成完整的可执行流程
• 逻辑层：具体的业务逻辑流程
• 实现层：实现业务逻辑中可替换逻辑的具体实现

而ifelse将代码分成了两部分：

• 调用层：将下层的业务逻辑组装起来，形成完整的可执行流程
• 逻辑层：具体的业务逻辑流程及具体逻辑

解耦

在ifelse实现中，「逻辑流程」和「逻辑实现」是硬编码在一起的，明显的紧耦合。而策略模式将「逻辑流程」和「逻辑实现」拆分开，对其进行了解耦。

解耦后，「逻辑流程」和「逻辑实现」就可以独立的进化，而不会相互影响。

独立进化

假设现在要调整业务流程。对于策略模式来说，需要修改的是「逻辑层」；而对于ifelse来说，需要修改的也是「逻辑层」。

假设现在要新增一个策略。对于策略模式来说，需要修改的是「实现层」；而对于ifelse来说，需要修改的还是「逻辑层」。

在软件开发中，有一个原则叫单一职责原则，它不仅仅是针对类或方法的，它也适用于包、模块甚至子系统。

对应到这里，你会发现，ifelse的实现方式违背了单一职责原则。使用ifelse实现，使得逻辑层的职责不单一了。当业务流程需要调整时，需要调整逻辑层的代码；当具体的业务逻辑实现需要调整时，也需要调整逻辑层。

而策略模式将业务流程和具体的业务逻辑拆分到了不同的层内，使得每一层的职责相对的单一，也就可以独立的进化。

对象聚集

我们重新来观察一下策略模式的架构图，再对照上面的调用代码，你有没有发现缺少了点什么？

在Client中，我们要根据参数判定来实例化了StategyA或StategyB对象。也就是说，「调用层」使用了「实现层」的代码，实际调用逻辑应该是这样的：

可以看到，Client与StategyA和StategyB是强依赖的。这会导致两个问题：

• 对象分散：如果StategyA或StategyB的实例化方法需要调整，所有实例化代码都需要进行调整。或者如果新增了StategyC，那么所有将Stategy设置到Context的相关代码都需要调整。
• 稳定层依赖不稳定层：一般情况下，「实现层」的变动频率较高；而对于「调用层」来说，调用流程确定后，基本就不会变化了。让一个基本不变的层去强依赖一个频繁变化的层，显然是有问题的。

我们先来解决「对象分散」的问题，下一节来解决「稳定层依赖不稳定层」的问题！

（编辑：西安站长网）

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