代理设计模式的UML图：

这个例子非常简单，只有一个方法wirteCode的接口IDeveloper:

测试代码：

测试输出：

现在麻烦的是，Jerry的领导因为团队中的开发者像Jerry一样没有编写技术文档，所以并不满意。经过讨论后，整个团队达成协议，相关文档必须与代码一起提供。

为了迫使开发人员编写文档而不直接对现有的实现类Developer进行修改，现在就可以使用静态代理来实现：

测试代码：

测试输出：

假设你希望在不修改原始类代码的情况下增强现有的稳定实现，你可以创建一个代理类，并将原始实现封装为代理中的私有属性。增强的功能是在代理类中完成的，对现有的代码是完全透明的。回到上面的示例，客户端代码并不关心它用来调用writeCode()方法的变量是否指向真正的开发人员或开发人员代码。

优点：

我们仍然使用这个例子来说明。
假设现在缺失文档的问题在QA同事中仍然存在。如果我们想通过静态代理来解决这个问题，那么必须引入另一个代理类。

这是测试人员的接口：

测试人员代理：

测试代码和输出：

从Tester代理的源代码中我们可以很容易的观察到它与开发人员具有完全相同的逻辑。如果又过了一段时间，我们必须为软件交付过程中的其他同事建立文档，我们必须一次又一次的引入新的静态代理类，这会导致静态代理类变得十分庞大。

现在我通过代理类EnginnerProxy来为所有的具体角色提供代理服务，而不是单独为每个原始实现类设置专用的静态代理类。

下面是如何使用InvocationHandler设计的动态代理和测试输出：

虽然这个变体成功的避免了静态代理中的重复缺陷，但是它仍然有一个局限性，它无法使用不是从接口继承的实现类，就是说，使用动态代理类，原始类必须先要实现一个或多个接口，这个接口也就是代理接口。

考虑下面的例子，产品所有者没有实现任何接口：

以下代码在IDE中没有任何语法错误：

不幸的是编译时报出了以下错误：