设计模式总结篇系列：代理模式（Proxy）

时代在发展，我们发现，现在不少明星都开始进行微访谈之类的，有越来越多的参与捐赠等。新的一天开始了，首先看下新的一天的日程安排：

interface Schedule{
    
    public void weiTalk();
    
    public void donation();
    
}

Schedule接口定义了今天的形成安排，主要包括微访谈和捐款。那么看一下实现此接口的明星类定义：

class Star implements Schedule {

    @Override
    public void weiTalk() {
        System.out.println("开始微访谈");
    }

    @Override
    public void donation() {
        System.out.println("开始捐款");
    }

}

我们知道，现在明星一般的身边都有一个人，称之为经纪人，负责明星的工作安排及各种事物处理等。一般明星到哪，相应的经纪人也就到哪。我们来定义一个经纪人：

class Broker implements Schedule {
    private Schedule star;

    public Broker() {
        star = new Star();
    }

    public Broker(Schedule star) {
        this.star = star;
    }

    @Override
    public void weiTalk() {
        System.out.println("陪着明星参加为访谈");
        star.weiTalk();
    }

    @Override
    public void donation() {
        System.out.println("陪着明星捐款");
        star.donation();
    }

}

我们知道，Broker虽然也需要参加微访谈和捐款，但都是陪着明星的，例如现在正在微博访谈，网友问了一个问题：你希望你的小neinei尽快长大呢？WZ回答，当然不是很希望啦。于是经纪人在WZ的微博中回复网友：当然不是很希望啦。

我们发现，Broker对象实现的方法中实际上调用的还是相应所持有的Star对象引用中相应的方法。好，假如正在微访谈过程中，小neinei睡醒了，嚷嚷着爸爸去哪了，于是WZ只得马上跑过去哄自己心爱的小neinei。可这时候网友们还在提问啊，怎么办呢，经纪人总不能擅自做主张的直接回答网友问题吧，于是向网友解释：小neinei醒了，WZ去哄她睡觉了，微访谈顺延到21：30。

又或者在去参与捐赠会的路上，突然剧组那边有更重要的发布会要Star过去，这时候捐赠会主办方打电话过来询问代理们是不是快要到了，代理当即回答，Star临时有更重要的事情要处理，就不去参加了，当然，钱肯定还是会给的。

在外界看来，一般情况下无论是接商务广告还是友情出演，首先都是联系Broker的，等Broker和Star商量后作出决定并有Broker对外回复。

上面整个过程中，外界与Star是不能直接接触的，或者说要先有代理的安排，Broker和Star之间的关系是代理和被代理的关系。这种设计模式我们称之为代理模式。可能有人会说，怎么感觉跟装饰器模式那么像呢？确实，在代码层次而言，两者确实比较接近。而主要的不同在于两个模式背后所蕴含的思想：

装饰器模式主要用来替代继承，为的是给一个现有的类增加新的功能，客户端关心的是装饰后的类所具有的功能；而代理模式为的是对被代理对象提供访问控制，客户端关心的实际上还是被代理对象所具有的功能。