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
1700460220
我相信第一次接触到代理模式的读者肯定很郁闷，为什么要用代理呀？想想现实世界吧，打官司为什么要找个律师？因为你不想参与中间过程的是是非非，只要完成自己的答辩就成，其他的比如事前调查、事后追查都由律师来搞定，这就是为了减轻你的负担。代理模式的使用场景非常多，大家可以看看Spring AOP，这是一个非常典型的动态代理。
1700460221
1700460222
1700460223
1700460224
1700460225
设计模式之禅 [:1700453965]
1700460226
设计模式之禅 12.4 代理模式的扩展
1700460227
1700460228
12.4.1 普通代理
1700460229
1700460230
在网络上代理服务器设置分为透明代理和普通代理，是什么意思呢？透明代理就是用户不用设置代理服务器地址，就可以直接访问，也就是说代理服务器对用户来说是透明的，不用知道它存在的；普通代理则是需要用户自己设置代理服务器的IP地址，用户必须知道代理的存在。我们设计模式中的普通代理和强制代理也是类似的一种结构，普通代理就是我们要知道代理的存在，也就是类似的GamePlayerProxy这个类的存在，然后才能访问；强制代理则是调用者直接调用真实角色，而不用关心代理是否存在，其代理的产生是由真实角色决定的，这样的解释还是比较复杂，我们还是用实例来讲解。
1700460231
1700460232
首先说普通代理，它的要求就是客户端只能访问代理角色，而不能访问真实角色，这是比较简单的。我们以上面的例子作为扩展，我自己作为一个游戏玩家，我肯定自己不练级了，也就是场景类不能再直接new一个GamePlayer对象了，它必须由GampePlayerProxy来进行模拟场景，类图修改如图12-4所示。
1700460233
1700460234
1700460235
1700460236
1700460237
图12-4 普通代理类图
1700460238
1700460239
改动很小，仅仅修改了两个实现类的构造函数，GamePlayer的构造函数增加了_gamePlayer参数，而代理角色则只要传入代理者名字即可，而不需要说是替哪个对象做代理。GamePlayer类如代码清单12-10所示。
1700460240
1700460241
代码清单12-10 普通代理的游戏者
1700460242
1700460243
public class GamePlayer implements IGamePlayer{
1700460244
1700460245
private String name=””；
1700460246
1700460247
//构造函数限制谁能创建对象，并同时传递姓名
1700460248
1700460249
public GamePlayer（IGamePlayer_gamePlayer,String_name）throws Exception{