1700460170
1700460171
//善后处理
1700460172
1700460173
private void after（）{
1700460174
1700460175
//do something
1700460176
1700460177
}
1700460178
1700460179
}
1700460180
1700460181
看到这里，大家别惊讶，为什么会出现before和after方法，继续看下去，这是一个“引子”，能够引出一个崭新的编程模式。
1700460182
1700460183
一个代理类可以代理多个被委托者或被代理者，因此一个代理类具体代理哪个真实主题角色，是由场景类决定的。当然，最简单的情况就是一个主题类和一个代理类，这是最简洁的代理模式。在通常情况下，一个接口只需要一个代理类就可以了，具体代理哪个实现类由高层模块来决定，也就是在代理类的构造函数中传递被代理者，例如我们可以在代理类Proxy中增加如代码清单12-9所示的构造函数。
1700460184
1700460185
代码清单12-9 代理的构造函数
1700460186
1700460187
public Proxy（Subject_subject）{
1700460188
1700460189
this.subject=_subject；
1700460190
1700460191
}
1700460192
1700460193
你要代理谁就产生该代理的实例，然后把被代理者传递进来，该模式在实际的项目应用中比较广泛。
1700460194
1700460195
1700460196
1700460197
1700460199
设计模式之禅 12.3 代理模式的应用
1700460200
1700460201
12.3.1 代理模式的优点
1700460202
1700460203
❑职责清晰
1700460204
1700460205
真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件事务，附带的结果就是编程简洁清晰。
1700460206
1700460207
❑高扩展性
1700460208
1700460209
具体主题角色是随时都会发生变化的，只要它实现了接口，甭管它如何变化，都逃不脱如来佛的手掌（接口），那我们的代理类完全就可以在不做任何修改的情况下使用。
1700460210
1700460211
❑智能化
1700460212
1700460213
这在我们以上的讲解中还没有体现出来，不过在我们以下的动态代理章节中你就会看到代理的智能化有兴趣的读者也可以看看Struts是如何把表单元素映射到对象上的。
1700460214
1700460215
1700460216
1700460217
1700460218
设计模式之禅 12.3.2 代理模式的使用场景
1700460219
[
上一页 ]
[ :1.70046017e+09 ]
[
下一页 ]