事例

小张是一个普普通通的码农，天天勤勤恳恳地码代码。某天中午小张刚要去用饭，一个电话打到了他的手机上。“是XX公司的小张吗？我是YY公司的王AA”。“哦，是王总啊，有什么工作吗？”。相同事后，小张弄大白了,本来客户有个需求，恰好认真这方面开拓的是小张，劳务派遣管理系统，客户就直接找到了他。不外小张却没有承诺客户的请求，软件开发，而是让客户找产物司理小李相同。

是小张着急去吃面而甩锅吗？并不是，只是为了使故事可以套到署理模式上。我们先看一下署理模式的界说： * 为其他工具提供一种署理，以节制对这个工具的会见。(Provide a surrogate or placeholder for another object to control access to it)

比较界说，码农小张可以映射为其他工具，产物司理小李为小张的署理。我们通过JAVA代码，表述上面事例。

静态署理

1.抽象脚色

基于面向工具的思想，首先界说一个码农接口,它有一个实现用户需求的要领。

java; gutter: true">public interface ICoder {

    public void implDemands(String demandName);

}

2.真实脚色

我们假设小张是JAVA措施员，界说一个JAVA码农类，他通过JAA语言实现需求。

java; gutter: true">public class JavaCoder implements ICoder{

    private String name;

    public JavaCoder(String name){
        this.name = name;
    }

    @Override
    public void implDemands(String demandName) {
        System.out.println(name + " implemented demand:" + demandName + " in JAVA!");
    }
}

3.署理脚色

委屈一下产物司理，将其定名为码农署理类，软件开发，同时让他实现ICoder接口。

public class CoderProxy implements ICoder{

    private ICoder coder;

    public CoderProxy(ICoder coder){
        this.coder = coder;
    }

    @Override
    public void implDemands(String demandName) {
        coder.implDemands(demandName);
    }
}

上面一个接口，两个类，就实现了署理模式。Are you kidding me？这么简朴？是的，就是这么简朴。 我们通过一个场景类，模仿用户找产物司理增加需求。

public class Customer {

    public static void main(String args[]){
        //界说一个java码农
        ICoder coder = new JavaCoder("Zhang");
        //界说一个产物司理
        ICoder proxy = new CoderProxy(coder);
        //让产物司理实现一个需求
        proxy.implDemands();
    }
}

运行措施，功效如下：

Zhang implemented demand:Add user manageMent in JAVA!

产物司理充当了措施员的署理，客户把需求汇报产物司理，并不需要和措施员打仗。看到这里，有些机警的措施员发明白问题。你看，产物司理就把客户的需求传达了一下，怪不得我看产物司理这么不爽。

产物司理虽然不可是传达用户需求，他尚有许多工作可以做。好比，该项目抉择不接管新增成果的需求了，对修CoderProxy类做一些修改：

public class CoderProxy implements ICoder{

    private ICoder coder;

    public CoderProxy(ICoder coder){
        this.coder = coder;
    }

    @Override
    public void implDemands(String demandName) {
        if(demandName.startsWith("Add")){
            System.out.println("No longer receive 'Add' demand");
            return;
        }
        coder.implDemands(demandName);
    }
}

这样，当客户再有增加成果的需求时，产物司理就直接谢绝了，措施员无需再对这部门需求做过滤。

总结

我们对上面的事例做一个简朴的抽象：

署理模式包括如下脚色：

署理模式利益：

动态署理

前面讲的主要是静态署理。那么什么是动态署理呢？

假设有这么一个需求，在要领执行前和执行完成后，打印系统时间。这很简朴嘛，非业务逻辑，只要在署理类挪用真实脚色的要领前、后输出时间就可以了。像上例，只有一个implDemands要领，这样实现没有问题。但假如然实脚色有10个要领，那么我们要写10遍完全沟通的代码。有点追求的码农，必定会对这种要领感想很是不爽。有些机警的小同伴大概想到了用AOP办理这个问题。很是正确。岂非AOP和动态署理有什么干系？没错！AOP用的恰恰是动态署理。