结构型设计模式（二）（外观模式，享元模式，代理模式）

外观模式

为子系统提供一个更高层次的，更简单的接口。降低客户与子系统的耦合度。现在多是分布式服务。外观模式就发挥了很大的作用。对于客户的一个对子系统的需求不需要直接与子系统交互。而是通过门面角色（接口）来进行操作。看一下类图：

仍然以我们买衣服为例。我们买衣服需要买外套，和裤子。卖外套和卖裤子则相当于俩个子系统。不使用外观模式。我们需要new一个卖外套实例一个卖裤子实例，然后分别调用它们的方法。这样客户和子系统的耦合度就较高（假如有10000个子系统），而使用外观模式，我们可以创建一个门面类。里面包含了卖衣服和卖裤子的方法，在实现时，我们只需和门面类就可以，不用和每个子系统进行交互。

具体代码实现呢我们给出门面的Java实现（以上面例子为例）：

public class Facade {
private 外套 外套；
private 裤子 裤子
public Facade(外套 外套,裤子 裤子){
this.裤子 = 裤子;
this.外套 = 外套;
}
public void 买衣服(){
外套.买外套();
裤子.买裤子();
}
}

享元模式

用一个共享来避免大量拥有相同内容对象的开销。对象状态分为内蕴状态和外蕴状态。内蕴状态不会随环境而改变也就是共享的部分。外蕴状态是随环境改变而改变的，并且状态由客户端保存。不可共享。同样看一下类图：

有类图可以看出，在享元模式中我们有用到单例模式（工厂），对于享元的理解。我们可以以String类型为例。由于享元主要用于解决系统性能问题。而在项目中并不常用（使系统复杂化）。这里不多讲了，理解就好》

代理模式

说到代理模式，我想大家都不陌生，应该都有接触，比如著名的Spring中的面向切面编程的AOP。先看一下类图：

有类图可以看出，代理类，真实类必须实现统一接口。

来个例子

生活中的例子：过年加班比较忙，没空去买火车票，这时可以打个电话到附近的票务中心，叫他们帮你买张回家的火车票，当然这会附加额外的劳务费。但要清楚票务中心自己并不卖票，只有火车站才真正卖票，票务中心卖给你的票其实是通过火车站实现的。这点很重要！

上面这个例子，你就是“客户”，票务中心就是“代理角色”，火车站是“真实角色”，卖票称为“抽象角色”！

 1 // 抽象角色：抽象类或接口
 2 interface  Business
 3 {
 4    void doAction();
 5}
 6 // 真实角色：真正实现了业务逻辑接口
 7 class  BusinessImpl  implements  Business
 8 {
 9    public void doAction()
10    {
11        System.out.println("真实角色中的方法被执行！");
12    }
13}
14 // 代理角色：自己并未实现业务逻辑接口，而是调用真实角色来实现
15 class  BusinessImplProxy  implements  Business
16 {
17    private BusinessImpl bi;
18    public void doAction()
19    {
20        if (bi==null)
21        {
22            bi = new BusinessImpl();
23        }
24        doBefore();
25        bi.doAction();
26        doAfter();
27    }
28    public void doBefore()
29    {
30        System.out.println("前置处理！");
31    }
32    public void doAfter()
33    {
34        System.out.println("后置处理！");
35    }
36}
37 // 测试类
38 class  Test
39 {
40    public static void main(String[] args)
41    {
42        //引用变量定义为抽象角色类型
43        Business bi = new BusinessImplProxy();
44        bi.doAction();
45    }
46}
47