相比很多人都知道代理模式吧，我觉得不实现相同的接口，代理主题内部含有对真实主题的引用，照样能够使得任何使用真实主题的地方都可以使用代理主题，也可以在将调用传递给真实主题之前或之后执行一些额外的操作,达到控制真实主题的目的，那么为什么非要强制他们实现相同的接口那？
如果你单纯的站在实现代理功能这个角度来看，那的确没必要非要实现什么接口，
站在灵活性设计的角度，也就是真实应用中那一定是面向接口编程，
你说的就不叫代理模式了，它本身就是针对相同的接口编程，以达到透明地替换原来的对象
你这样搞一个新的类，这叫委托模式了，
打个比方，要代理的类为A,它实现的接口为I,用户代码依赖于接口I,你用代理模式
的话，代理类还是实现了接口I,这样用户代码不用修改，还是依赖于接口I.
但如果使用委托模式的话，你的那个委托类为B，B没有实现接口I。
那用户代码就得依赖于B，还不是原来的I
你觉得这样要修改用户代码的方式好吗？
其实就静态代理来说，个人认为不实现相同的接口也可以，不过实现相同的接口就保证了代理对象具有和被代理对象具有一样的契约。体现了“代理”的概念。
而且你说的这种“静态代理“其实和装饰器很象，个人觉得设计模式不必太拘泥理论，理解精髓更重要。
产生实例没关系，问题是面向接口编程，能够很好的透明替换实现类，而不用修改代码
[quote]貌似如果仅仅是有相同的契约在这里没有什么实际意义啊？[/quote]
当然有实际意义，如果都实现了相同的接口，比如说IInterface，那么实践中客户端调用代码就是：
IInterface itf = ...;
后面即可以产生被代理对象，也可以产生代理对象，也可以把对象注入进行，是有意义的。
当然可以不需要，只提供一个创建实例的方法就行了，用户代码只依赖接口I
比如
用户代码如下使用：
I obj = Instance.createI();
//这样使用者只依赖于I
class Instance {
public I createI()
{
//这里用代理类还是原始类就看情况了，还可以通过配置文件的方式来动态切换
}
}
应该使用：
[quote]IInterface p=new Proxy();
p.xxx();//xxx方法中调用了被代理类的方法 [/quote]
这里的p是可以传到其它方法里，方法中有一个IInterface 的参数.