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

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

一般模式讲解套路

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

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

以策略模式为例：

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

适用性：

• 许多相关的类仅仅是行为有异。「策略」提供了一种用多个行为中的一个行为来配置一个类的方法。
• 需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时，可以使用策略模式。
• 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
• 一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

类结构：

示例代码：

public class Context { 
 
 //持有一个具体策略的对象 
 private Strategy strategy; 
 
 /** 
 * 构造函数，传入一个具体策略对象 
 * @param strategy 具体策略对象 
 */ 
 public Context(Strategy strategy){ 
 this.strategy = strategy; 
 } 
  
 /** 
 * 策略方法 
 */ 
 public void invoke(){ 
 strategy.doInvoke(); 
 } 
} 
 
public interface Strategy { 
 
 /** 
 * 策略方法 
 */ 
 public void doInvoke(); 
} 
 
public class StrategyA implements Strategy { 
 
 @Override 
 public void doInvoke() { 
 System.out.println("InvokeA"); 
 } 
} 
 
public class StrategyB implements Strategy { 
 @Override 
 public void doInvoke() { 
 System.out.println("InvokeB"); 
 } 
} 

从上面的讲解，你能理解策略模式吗？你是否有如下的一些疑问？

• 使用策略模式和我直接写if-else具体的优势在哪里？
• if-else不是挺简单的，为什么要多写这么多的类？
• 如何将Strategy给设置到Context中？
• 我该如何判断将哪个实现设置给Context？还是ifelse？！那拆成这么多的类不是脱裤子放屁吗？

将模式放入架构中

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

当我们将其放到实际项目中时，我们实际是需要一个客户端来组装和调用这个设计模式的，如下图所示：

public class Client { 
  
 public static void main(String[] args) { 
 Strategy strategy; 
 if("A".equals(args[0])) { 
 strategy = new StrategyA(); 
 } else { 
 strategy = new StrategyB(); 
 } 
 Context context = new Context(strategy); 
 context.invoke(); 
 }  
} 

作为比较，这里也给出直接使用ifelse时的结构和代码：

public class Client { 
 public static void main(String[] args) { 
 Context context = new Context(args[0]); 
 context.invoke(); 
 } 
} 
 
public class Context { 
 public void invoke(String type) { 
 if("A".equals(type)) { 
 System.out.println("InvokeA"); 
 } else if("B".equals(type)) { 
 System.out.println("InvokeB"); 
 } 
 } 
} 

乍看之下，使用ifelse更加的简单明了，不过别急，下面我们来对比一下两种实现方式的区别，来具体看看设计模式所带来的优势。

边界不同

（编辑：ASP站长网）