1700460350
1700460351
//开始打游戏，记下时间戳
1700460352
1700460353
System.out.println（“开始时间是：2009-8-25 10:45”）；
1700460354
1700460355
proxy.login（“zhangSan”，“password”）；
1700460356
1700460357
//开始杀怪
1700460358
1700460359
proxy.killBoss（）；
1700460360
1700460361
//升级
1700460362
1700460363
proxy.upgrade（）；
1700460364
1700460365
//记录结束游戏时间
1700460366
1700460367
System.out.println（“结束时间是：2009-8-26 03:40”）；
1700460368
1700460369
}
1700460370
1700460371
}
1700460372
1700460373
运行结果完全相同。在该模式下，调用者只知代理而不用知道真实的角色是谁，屏蔽了真实角色的变更对高层模块的影响，真实的主题角色想怎么修改就怎么修改，对高层次的模块没有任何的影响，只要你实现了接口所对应的方法，该模式非常适合对扩展性要求较高的场合。当然，在实际的项目中，一般都是通过约定来禁止new一个真实的角色，这也是一个非常好的方案。
1700460374
1700460375
注意 普通代理模式的约束问题，尽量通过团队内的编程规范类约束，因为每一个主题类是可被重用的和可维护的，使用技术约束的方式对系统维护是一种非常不利的因素。
1700460376
1700460377
1700460378
1700460379
1700460380
设计模式之禅 12.4.2 强制代理
1700460381
1700460382
强制代理在设计模式中比较另类，为什么这么说呢？一般的思维都是通过代理找到真实的角色，但是强制代理却是要“强制”，你必须通过真实角色查找到代理角色，否则你不能访问。甭管你是通过代理类还是通过直接new一个主题角色类，都不能访问，只有通过真实角色指定的代理类才可以访问，也就是说由真实角色管理代理角色。这么说吧，高层模块new了一个真实角色的对象，返回的却是代理角色，这就好比是你和一个明星比较熟，相互认识，有件事情你需要向她确认一下，于是你就直接拨通了明星的电话：
1700460383
1700460384
“喂，沙比呀，我要见一下XXX导演，你帮下忙了！”
1700460385
1700460386
“不行呀衰哥，我这几天很忙呀，你找我的经纪人吧……”
1700460387
1700460388
郁闷了吧，你是想直接绕过她的代理，谁知道返回的还是她的代理，这就是强制代理，你可以不用知道代理存在，但是你的所作所为还是需要代理为你提供。我们把上面的例子稍作修改就可以完成，如图12-5所示。
1700460389
1700460390
1700460391
1700460392
1700460393
图12-5 强制代理类图
1700460394
1700460395
在接口上增加了一个getProxy方法，真实角色GamePlayer可以指定一个自己的代理，除了代理外谁都不能访问。我们来看代码，先看IGamePlayer接口，如代码清单12-13所示。
1700460396
1700460397
代码清单12-13 强制代理的接口类
1700460398
1700460399
public interface IGamePlayer{