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{
1700460400
1700460401
//登录游戏
1700460402
1700460403
public void login（String user,String password）；
1700460404
1700460405
//杀怪，这是网络游戏的主要特色
1700460406
1700460407
public void killBoss（）；
1700460408
1700460409
//升级
1700460410
1700460411
public void upgrade（）；
1700460412
1700460413
//每个人都可以找一下自己的代理
1700460414
1700460415
public IGamePlayer getProxy（）；
1700460416
1700460417
}
1700460418
1700460419
仅仅增加了一个getProxy方法，指定要访问自己必须通过哪个代理，实现类也要做适当的修改，先看真实角色GamePlayer，如代码清单12-14所示。