讲解设计模式的书或者文章，都是从代码层面来讲解设计模式，看的时候都懂，但是到真正用的时候，还是理不清、想不明。

本文尝试从架构层面来聊一聊设计模式。通过将使用设计模式的代码和不使用设计模式的代码分别放到架构中，来看看设计模式对架构所产生的影响。

一般模式讲解套路

一般讲解设计模式的套路是：

• 说明模式的意图
• 说明模式的适用场景
• 给出模式的类结构
• 给出对应的代码示例

以策略模式为例：

意图：定义一系列的算法，把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

适用性：

• 许多相关的类仅仅是行为有异。「策略」提供了一种用多个行为中的一个行为来配置一个类的方法。
• 需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时，可以使用策略模式。
• 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
• 一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的St面的讲解，你能理解策略模式吗？你是否有如下的一些疑问？
  • 使用策略模式和我直接写if-else具体的优势在哪里？
  • if-else不是挺简单的，为什么要多写这么多的类？
  • 如何将Strategy给设置到Context中？
  • 我该如何判断将哪个实现设置给Context？还是ifelse？！那拆成这么多的类不是脱裤子放屁吗？

  将模式放入架构中

  产生这些疑问的原因，是我们在孤立的看设计模式，而没有把设计模式放到实际的场景中。

  当我们将其放到实际项目中时，我们实际是需要一个之下，使用ifelse更加的简单明了，不过别急，下面我们来对比一下两种实现方式的区别，来具体看看设计模式所带来的优势。

  边界不同

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

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

（编辑：应用网_丽江站长网）

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