无内功传奇私服,轩辕传奇私服攻略,仿盛大1.76金币合击版
&&当前位置：>>公路文化>>
无内功传奇私服,轩辕传奇私服攻略,仿盛大1.76金币合击版
发布日期:&作者:何欣&&&&单位:&&
&&& 我们坚持将&爱心&。
&&& 今年，，，配齐了暖气、电扇，检修了电话、电视、DVD等设施，，，、食品等。
光与暗6传奇私服
】【】【】&&&如何看待混合学习模式下学生学习负担增加
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
如何看待混合学习模式下学生学习负担增加
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口扫一扫下载手机客户端
扫描我，关注团购信息，享更多优惠
||网络安全
| | | | | | | | | | | | | | | |
||电子电工
汽车交通| | | | | | | | | |
||投资理财
| | | | | | | | | | | | | | | | |
| | | | | | |
| | | | | | | | | | | | | | | | | | |
| | | | | | |||
||外语考试
| | | | | | | | |
| 视频教程|
设计模式之禅(第2版)
设计模式领域公认的3本经典著作之一，“极具趣味，容易理解，但讲解又极为严谨和透彻”
定价：￥89.00
校园优惠价：￥58.74 (66折)
促销活动：
商品已成功飞到您的手机啦！快登录手机站看看吧！
下载客户端
> 微信关注“互动出版网”，便捷查询订单，更多惊喜天天有
ISBN：1上架时间：出版日期：2014 年2月开本：16开页码：555版次：2-1
所属分类：
　 畅销书全新升级，第1版广受好评，被誉为设计模式领域最具趣味、最易理解且又讲解极为透彻的一本书，程序员公认的3本经典设计模式著作之一
深刻解读6大设计原则和28种设计模式的准确定义、应用方法和最佳实践，全方位比较各种同类模式之间的异同，详细讲解组合使用不同模式的方法
《设计模式之禅（第2版）》是设计模式领域公认的3本经典著作之一，“极具趣味，容易理解，但讲解又极为严谨和透彻”是本书的写作风格和方法的最大特点。第1版2010年出版，畅销至今，广受好评，是该领域的里程碑著作。深刻解读6大设计原则和28种设计模式的准确定义、应用方法和最佳实践，全方位比较各种同类模式之间的异同，详细讲解将不同的模式组合使用的方法。第2版在第1版的基础上有两方面的改进，一方面结合读者的意见和建议对原有内容中的瑕疵进行了修正和完善，另一方面增加了4种新的设计模式，希望这一版能为广大程序员们奉上一场更加完美的设计模式盛宴！
全书共38章，分为五部分：第一部分（第1～6章），以一种全新的视角对面向对象程序设计的6大原则进行了深刻解读，旨在让读者能更深刻且准确地理解这些原则，为后面的学习打下基础；第二部分（第7～29章）通过大量生动的案例讲解和分析了23种最常用的设计模式，并进行了扩展讲解，通俗易懂，趣味性极强而又紧扣模式的核心；第三部分（第30～33章）对同类型和相关联的模式进行了深入分析和比较，旨在阐明各种设计模式之间的差别以及它们的理想应用场景；第四部分（第34～36章）探讨了如何在实际开发中将各种设计模式混合起来使用，以发挥设计模式的最大效用；第五部分（第37～38章）是本书的扩展篇，首先从实现的角度对MVC框架的原理进行了深入分析，然后讲解了5种新的设计模式的原理、意图和最佳实践。本书最后附有一份精美的设计模式彩图，可以裁剪，便于参考。
秦小波，资深软件开发工程师、系统分析师和架构师(获Sun架构师认证)，从事软件开发工作10余年，实践经验极其丰富。精通设计模式，对设计模式有深刻的认识和独到见解，经过长期大量的实践和总结，创造性地提出新的设计模式。资深Java技术专家，精通Spring、Struts 2、Hibernate、iBatis、iBPM等Java技术，在企业级Java应用领域积累了大量经验，对基于ESB、BPEL的服务集成技术也有深入的认识。此外，还是一位优秀的DBA，具有IBM DB2 DBA资格认证，对海量数据处理有深入的研究。著有畅销书《编写高质量代码：改善Java程序的151个建议》，广受读者好评!
《设计模式之禅（第2版）》
大旗不挥，谁敢冲锋―6大设计原则全新解读
单一职责原则 2
我是“牛”类，我可以担任多职吗 2
绝杀技，打破你的传统思维 3
我单纯，所以我快乐 6
最佳实践 7
里氏替换原则 8
爱恨纠葛的父子关系 8
纠纷不断，规则压制 9
最佳实践 18
依赖倒置原则 19
依赖倒置原则的定义 19
言而无信，你太需要契约 20
依赖的三种写法 25
最佳实践 26
接口隔离原则 28
接口隔离原则的定义 28
美女何其多，观点各不同 29
　　为什么写这本书
　　2009年5月份，我在JavaEye上发了一个帖子，其中提到自己已经工作9年了，总觉得这9年不应该就这么荒废了，应该给自己这9年的工作写一个总结，总结的初稿就是这本书。
　　在谈为什么写这本书之前，先抖抖自己前9年的职业生涯吧。大学时我是学习机械的，当时计算机刚刚热起来，自己也喜欢玩一些新奇的东西，记得最清楚的是用VB写了一个自由落体的小程序，模拟小球从桌面掉到地板上，然后计算反弹趋势，很有成就感。于是2000年毕业时，我削尖了脑袋进入了IT行业，成为了一名真正的IT男，干着起得比鸡早、睡得比狗晚的程序员工作，IT男的辛酸有谁知晓！
　　坦白地说，我的性格比较沉闷，属于典型的程序员型闷骚，比较适合做技术研究。在这9年里，项目管理做过，系统分析做过，小兵当过，团队领导人也当过，但至今还是一个做技术的。要总结这9年技术生涯，总得写点什么吧，最好是还能对其他人有点儿用的。那写什么好呢？Spring、Struts等工具框架类的书太多太多，很难再写出花样来，经过一番思考，最后选择了一个每一位技术人员都需要掌握的、但普及程度还不是非常高的、又稍微有点难度的主题―设计模式（Design Pattern，DP）。
　　中国人有不破不立的思维，远的如秦始皇焚书坑儒、项羽火烧阿房宫，近的如破“四旧”。正是由于有了这样的思想，于是乎能改的就改，不能改的就推翻重写，没有一个持续开发蓝图。为什么要破才能立呢？为什么不能持续地发展？你说这是谁的错呢？是你架构师的错，你不能持续地拥抱变化，这是一个系统最失败的地方。那怎么才能实现拥抱变化的理想呢？设计模式！
　　设计模式是什么？它是一套理论，由软件界的先辈们（The Gang of Four：包括Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides）总结出的一套可以反复使用的经验，它可以提高代码的可重用性，增强系统的可维护性，以及解决一系列的复杂问题。做软件的人都知道需求是最难把握的，我们可以分析现有的需求，预测可能发生的变更，但是我们不能控制需求的变更。问题来了，既然需求的变更是不可控的，那如何拥抱变化呢？幸运的是，设计模式给了我们指导，专家们首先提出了6大设计原则，但这6大设计原则仅仅是一系列“口号”，真正付诸实施还需要有详尽的指导方法，于是23种设计模式出现了。
　　设计模式已经诞近20年了，其间出版了很多关于它的经典著作，相信大家都能如数家珍。尽管有这么多书，工作5年了还不知道什么是策略模式、状态模式、责任链模式的程序员大有人在。不信？你找个机会去“虚心”地请教一下你的同事，看看他对设计模式有多少了解。不要告诉我要翻书才明白！设计模式不是工具，它是软件开发的哲学，它能指导你如何去设计一个优秀的架构、编写一段健壮的代码、解决一个复杂的需求。
　　因为它是软件行业的经验总结，因此它具有更广泛的适应性，不管你使用什么编程语言，不管你遇到什么业务类型，设计模式都可以自由地“侵入”。
　　因为它不是工具，所以它没有一个可以具体测量的标尺，完全以你自己的理解为准，你认为自己多了解它，你就有可能产生多少的优秀代码和设计。
　　因为它是指导思想，你可以在此基础上自由发挥，甚至是自己设计出一套设计模式。
　　世界上最难的事有两件：一是让人心甘情愿地把钱掏出来给你，二是把自己的思想灌输到别人的脑子里。设计模式就属于第二种，它不是一种具体的技术，不像Struts、Spring、Hibernate等框架。一个工具用久了可以熟能生巧，就像砌墙的工人一样，长年累月地砌墙，他也知道如何把墙砌整齐，如何多快好省地干活，这是一个人的本能。我们把Struts用得很溜，把Spring用得很顺手，这非常好，但这只是一个合格的程序员应该具备的基本能力！于是我们被冠以代码工人（Code Worker）―软件行业的体力劳动者。
　　如果你通晓了这23种设计模式就不同了，你可以站在一个更高的层次去赏析程序代码、软件设计、架构，完成从代码工人到架构师的蜕变。注意，我说的是“通晓”，别告诉我你把23种设计模式的含义、适应性、优缺点都搞清楚了就是通晓。错了！没有工作经验的积累是不可能真正理解设计模式的，这就像大家小时候一直不明白为什么爸爸妈妈要工作而不能每天陪自己玩一样。
　　据说有的大学已经开了设计模式这门课，如果仅仅是几堂课，让学生对设计模式有一个初步的了解，我觉得并无不妥，但如果是专门的一门课程，我建议取消它！因为对一个尚无项目开发经验的学生来说，理解设计模式不是一般困难，而是非常非常困难！之前没有任何的实战经验，之后也没有可以立即付诸实践的场景，这样能理解设计模式吗？
　　在编写本书之前，23种设计模式我都用过，而且还算比较熟练，但是当真正要写到书中时，感觉心里没谱儿了。这个定义是这样的吗？是需要用抽象类还是应该用接口？为什么在这里不能抽取抽象呢？为什么在实际项目中这个模式要如此蜕化？这类小问题有时候很纠结，需要花费大量的精力和时间去分析和确认。所以，在写作的过程中我有过很多忧虑，担心书中会有太多瑕疵，这种忧虑现在仍然存在。遇到挫折的时候也气馁过，但是我坚信一句话：“开弓没有回头箭，回头即是空”，既然已经开始，就一定要圆满完成。
　　第2版与第1版的区别
　　本书是第2版，在写作中吸取了读者对上一版的许多意见和建议，修订了一些代码的变量、类、方法名称，以更加符合自然语言；删除了部分有争议的内容（如单例模式的垃圾回收问题）；修改了一些常用的名词，确保与编程人员的习惯相匹配。希望通过这些改进，给读者提供一个更完美的设计模式盛宴，弥补上一版中的诸多不足。
　　第2版第38章中新增了4种新的设计模式：对象池模式、雇工模式、黑板模式、空指针模式。这些模式是我们在实际工作中经常遇到，或者在开源代码时常看到的，但是我们却没有升级到“ 模式”这一理性高度。特别是像空指针模式，我们在编码中经常会遇到空值判断问题，但我们没有去想一想是否可以有更好的方式解决。第2版对空指针模式进行了讲解，虽然简单，但相信对你提升编码质量有很大的帮助。
　　本书的特色
　　简单、通俗、易懂，但又不肤浅，这是本书的最大特色。自己看过的技术书还算比较多，很痛恨那种大块头的巨著，搁家里当枕头都觉得太硬。如果要是再晦涩难懂点，那根本没法看，看起来实在是太累。设计模式原本就是理论性的知识，讲解的难度比较大，但我相信这本书能够把你对设计模式的恐惧一扫而光。不信？挑几页先看看！
　　我的理念是：像看小说一样阅读本书。我尽量用浅显通俗的语言讲解，尽量让你有继续看下去的欲望，尽量努力让你有兴趣进入设计模式的世界，兴趣是第一老师嘛！虽然我尽量让这本书浅显、通俗、易懂，但并不代表我的讲解就很肤浅。每个设计模式讲解完毕之后，我都附加了两个非常精华的部分：设计模式扩展和最佳实践，这是俺压箱底的技能了，为了博君一看，没招了，抖出来吧！尤为值得一提的是，本书还有设计模式PK和混编设计模式两部分内容教你如何自如地去运用这些设计模式，这是当前所有设计模式类的图书都不具备的，连最权威的那本书也不例外。
　　大旗不挥，谁敢冲锋
　　―6大设计原则全新解读
单一职责原则
里氏替换原则
依赖倒置原则
接口隔离原则
迪米特法则
开闭原则 单一职责原则
我是“牛”类，我可以担任多职吗
　　单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。这个设计原则备受争议，只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的。如果你是老大，看到一个接口或类是这样或那样设计的，你就问一句：“你设计的类符合SRP原则吗？”保准对方立马“萎缩”掉，而且还一脸崇拜地看着你，心想：“老大确实英明”。这个原则存在争议之处在哪里呢？就是对职责的定义，什么是类的职责，以及怎么划分类的职责。我们先举个例子来说明什么是单一职责原则。
　　只要做过项目，肯定要接触到用户、机构、角色管理这些模块，基本上使用的都是RBAC模型（Role-Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离），确实是一个很好的解决办法。我们这里要讲的是用户管理、修改用户的信息、增加机构（一个人属于多个机构）、增加角色等，用户有这么多的信息和行为要维护，我们就把这些写到一个接口中，都是用户管理类嘛，我们先来看它的类图，如图1-1所示。
　　太Easy的类图了，我相信，即使是一个初级的程序员也可以看出这个接口设计得有问题，用户的属性和用户的行为没有分开，这是一个严重的错误！这个接口确实设计得一团糟，应该把用户的信息抽取成一个BO（Business Object，业务对象），把行为抽取成一个Biz（Business Logic，业务逻辑），按照这个思路对类图进行修正，如图1-2所示。
　　重新拆封成两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。各位可能要说了，这个与我实际工作中用到的User类还是有差别的呀！别着急，我们先来看一看分拆成两个接口怎么使用。OK，我们现在是面向接口编程，所以产生了这个UserInfo对象之后，当然可以把它当IUserBO接口使用。也可以当IUserBiz接口使用，这要看你在什么地方使用了。要获得用户信息，就当是IUserBO的实现类；要是希望维护用户的信息，就把它当作IUserBiz的实现类就成了，如代码清单1-1所示。
职责划分后的类图
　　代码清单1-1
　　分清职责后的代码示例
　　......
　　IUserInfo userInfo = new UserInfo(); //
　　我要赋值了，我就认为它是一个纯粹的
　　BO IUserBO userBO =(IUserBO)userI
770)this.width=770;' />
系列图书推荐 ￥89.00￥58.74
作者其它作品￥69.00￥58.65
同类热销商品￥30.00￥21.60
订单处理配送
北京奥维博世图书发行有限公司 china-pub,All Rights Reserved代理模式 - cbf4life - 博客园
12.1 我是游戏至尊 &&&&& 2007年，感觉很无聊，于是就玩了一段时间的网络游戏，游戏名就不说了，要不就有做广告的嫌疑，反正就是打怪、升级、砍人、被人砍，然后继续打怪、升级、打怪、升级······我花了两个月的时间升级到80级，已经很有成就感了，但是还被人杀死，高手到处都是，GM（Game Master，游戏管理员）也不管，对于咱这种非RMB玩家基本上都是懒得搭理。在这段时间我是体会到网络游戏的乐与苦，参与家族（工会）攻城，胜利后那叫一个乐呀，感觉自己真是一个“狂暴战士”，无往不胜！那苦是什么呢？就是升级，为了升一级，就要到出杀怪，做任务，那个游戏还很变态，外挂管得很严，基本上出个外挂，没了两天就开始封账号，不敢用，升级基本上都要靠自己手打，累呀！我曾经的记录是连着打了23个小时，睡觉在梦中还和大BOSS在PK。有这样一段经历还是很有意思，作为架构师是不是可以把这段经历通过架构的方式记录下呢？当然可以了，我们把这段打游戏的过程系统化，非常简单的一个过程，如图12-1所示。
图12-1 游戏过程
&&&&& 太简单了，定义一个接口IGamePlayer，是所有喜爱网络游戏的玩家，然后定义一个具体的实现类GamePlayer，实现每个游戏爱好者为了玩游戏要执行的功能。代码也非常简单，我们先来看IGamePlayer，如代码清单12-1所示。
代码清单12-1 游戏者接口public interface IGamePlayer {
//登录游戏
public void login(String user,String password);
//杀怪，网络游戏的主要特色
public void killBoss();
public void upgrade();
&&&&& 非常简单，定义了三个方法，分别是我们在网络游戏中最常用的功能：登录游戏、杀怪和升级，其实现类如代码清单12-2所示。
代码清单12-2 游戏者public class GamePlayer implements IGamePlayer {
private String name = "";
//通过构造函数传递名称
public GamePlayer(String _name){
this.name = _
//打怪，最期望的就是杀老怪
public void killBoss() {
System.out.println(this.name + "在打怪！");
//进游戏之前你肯定要登录吧，这是一个必要条件
public void login(String user, String password) {
System.out.println("登录名为"+user + " 的用户 " + this.name + "登录成功！");
//升级，升级有很多方法，花钱买是一种，做任务也是一种
public void upgrade() {
System.out.println(this.name + " 又升了一级！");
&&&&& 在实现类中通过构造函数传递进来玩家姓名，方便进行后期的调试工作。我们通过一个场景类来模拟这样的游戏过程，如代码清单12-3所示。
代码清单12-3 场景类public class GamePlayer implements IGamePlayer {
private String name = "";
//通过构造函数传递名称
public GamePlayer(String _name){
this.name = _
//打怪，最期望的就是杀老怪
public void killBoss() {
System.out.println(this.name + "在打怪！");
//进游戏之前你肯定要登录吧，这是一个必要条件
public void login(String user, String password) {
System.out.println("登录名为"+user + " 的用户 " + this.name + "登录成功！");
//升级，升级有很多方法，花钱买是一种，做任务也是一种
public void upgrade() {
System.out.println(this.name + " 又升了一级！");
&&&&& 程序记录了游戏的开始时间和结束时间，同时也记录了在游戏过程中都需要做什么事情，运行结果如下：
开始时间是： 10:45
登录名为zhangSan 的用户 张三登录成功！
张三在打怪！
张三 又升了一级！
结束时间是： 03:40
&&&&& 运行结果也是我们想要的，记录我这段时间的网游生涯。心理学家告诉我们，人类对于苦难的记忆比对喜悦的记忆要深刻，但是人类对于喜悦是“趋利”性的，每个人都想Happy，都不想让苦难靠近，要想获得幸福，苦难也是再所难免的，我们的网游生涯也是如此，游戏打时间长了，腰酸背痛、眼涩干枯、手臂酸麻，等等，也就是网络成瘾综合症都出来了，其结果就类似吃了那个“一日丧命散”，“筋脉逆流，胡思乱想，而致走火入魔”。那怎么办呢？我们想玩游戏，但又不想碰触到游戏中的烦恼？如何解决呢？
&&&&& 有办法，现在游戏代练的公司非常多，我把自己的账号交给代练人员，由他们去帮我升级，去打怪，非常好的想法，我们来修改一下类图，如图12-2所示。
图12-2 游戏代练帮忙打怪
&&&&& 在类图中增加了一个GamePlayerProxy类来代表游戏代练者，它也不能有作弊的方法呀，游戏代练者也是手动打怪呀，因此同样继承IGamePlayer接口，其实现如代码清单12-4所示。
代码清单12-4 代练者public class GamePlayerProxy implements IGamePlayer {
private IGamePlayer gamePlayer =
//通过构造函数传递要对谁进行代练
public GamePlayerProxy(IGamePlayer _gamePlayer){
this.gamePlayer = _gameP
//代练杀怪
public void killBoss() {
this.gamePlayer.killBoss();
//代练登录
public void login(String user, String password) {
this.gamePlayer.login(user, password);
//代练升级
public void upgrade() {
this.gamePlayer.upgrade();
&&&&& 很简单，首先通过构造函数说明要代谁打怪升级，然后通过手动开始代用户打怪、升级。场景类Client代码也稍作改动，如代码清单12-5所示。
代码清单12-5 改进后的场景类public class Client {
public static void main(String[] args) {
//定义一个痴迷的玩家
IGamePlayer player = new GamePlayer("张三");
//然后再定义一个代练者
IGamePlayer proxy = new GamePlayerProxy(player);
//开始打游戏，记下时间戳
System.out.println("开始时间是： 10:45");
proxy.login("zhangSan", "password");
//开始杀怪
proxy.killBoss();
proxy.upgrade();
//记录结束游戏时间
System.out.println("结束时间是： 03:40");
&&&&& 运行结果也完全相同，还是张三这个用户在打怪，运行结果如下：
开始时间是： 10:45
登录名为zhangSan 的用户 张三登录成功！
张三在打怪！
张三 又升了一级！
结束时间是： 03:40
&&&&& 是的，没有任何改变，但是你有没有发觉，你的游戏已经在升级，有人在帮你干活了！终于升级到120级，然后基本上是本服无敌手，除了GM外，这个你可惹不起！这就是代理模式。
12.2 代理模式的定义
&&&&& 代理模式(Proxy Pattern)是一个使用率非常高的模式，其定义如下：
&&&&& provide a surrogate or placeholder for another object to control access to it. 为其他对象提供一种代理以控制对这个对象的访问。
&&&&& 代理模式的通用类图如图12-3所示。
图12-3 代理模式的通用类图
&&&&& 代理模式也叫做委托模式，它是一项基本设计技巧，许多其他的模式，如状态模式、策略模式、访问者模式本质上是在更特殊的场合采用了委托模式，而且在日常的应用中，代理模式可以提供非常好的访问控制，在一些著名开源软件中也经常见到它的身影，如Struts2的Form元素映射就采用了代理模式（准确的说是动态代理模式）。我们先看一下类图中的三个角色的定义：
Subject抽象主题角色
&&&&& 抽象主题类可以是抽象类也可以是接口，是一个最普通的业务类型定义，无特殊要求。
RealSubject 具体主题角色
&&&&& 也叫做被委托角色、被代理角色，它才是冤大头，是业务逻辑的具体执行者。
Proxy 代理主题角色
&&&&& 也叫做委托类、代理类，它负责对真实角色的应用，把所有抽象主题类定义的方法限制委托给真实主题角色实现，并且在真实主题角色处理完毕前后做预处理和善后处理工作。
&&&&& 我们首先来看Subject抽象主题类的通用源码，如代码清单12-6所示。
代码清单12-6 抽象主题类public interface Subject {
//定义一个方法
public void request();
&&&&& 在接口中我们定义了一个方法request来作为方法的代表，RealSubject对它进行实现，如代码清单12-7所示。
代码清单12-7 真实主题类public class RealSubject implements Subject {
//实现方法
public void request() {
//业务逻辑处理
&&&&& RealSubject是一个正常的业务实现类，代理模式的核心就在代理类上，如代码清单12-8所示。
代码清单12-8 代理类public class Proxy implements Subject {
//要代理哪个实现类
private Subject subject =
//默认被代理者
public Proxy(){
this.subject = new Proxy();
//通过构造函数传递代理者
public Proxy(Object...objects ){
//实现接口中定义的方法
public void request() {
this.before();
this.subject.request();
this.after();
private void before(){
//do something
//善后处理
private void after(){
//do something
&&&&& 看到这里，大家别惊讶，为什么会出现before和after方法，继续看下去，这是一个“引子”，能够引出一个崭新的编程模式。
&&&&& 一个代理类可以代理多个被委托者或被代理者，因此一个代理类具体代理哪个真实主题角色，是由场景类决定的，当然，最简单的情况就是一个主题类一个代理类，这是最简洁的代理模式。在通常情况下，一个接口只需要一个代理类就可以了，具体代理哪个实现类由高层模块来决定，也就是在代理类的构造函数中传递被代理者，例如我们可以在代理类Proxy中增加如代码清单12-9所示的构造函数。
代码清单12-9 代理的构造函数public Proxy(Subject _subject){
this.subject = _
&&&&& 你要代理谁，产生该代理的实例，然后把被代理者传递进来，该模式在实际的项目应用中比较广泛。
12.3 代理模式的应用
12.3.1 代理模式的优点
&&&&& 真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件完成事务，附带的结果就是编程简洁清晰。
&&&&& 具体主题角色是随时都会发生变化的，只要它实现了接口，甭管它如何变化，都逃不脱如来佛的手掌（接口），那我们的代理类完全就可以在不做任何修改的情况下使用。
&&&&& 这在我们以上讲解中还没有体现出来，不过在我们以下的动态代理章节中你就会看到代理的智能化，读者有兴趣也可以看看Struts是如何把表单元素映射到对象上的。
12.3.2 代理模式的应用
我相信第一次接触到代理模式的读者肯定很郁闷，为什么要用代理呀，是的，为什么要用代理？想想现实世界吧，你为什么要找代理律师，你去打官司，为什么要找个律师？因为你不想参与中间过程的是是非非，只要完成自己的答辩就成，其他的比如事前调查、事后追查都由律师来搞定，这就是为了减轻你的负担。代理模式使用非常多，大家可以看看Spring AOP，这是一个非常典型的动态代理。
12.4 代理模式的扩展
12.4.1 普通代理
&&&&& 在网络上代理服务器设置分为透明代理和普通代理，是什么意思呢？透明代理就是用户不用设置代理服务器地址，就可以直接访问，也就是说代理服务器对用户来说透明的，看不到，不用知道它存在的；普通代理则是需要用户自己设置代理服务器的IP地址，用户必须知道代理的存在。我们设计模式中的普通代理和强制代理也是类似的一种结构，普通代理就是我们要知道代理的存在，也就是类似的GamePlayerProxy这个类的存在，然后才能访问；强制代理则是调用者直接调用真实角色，而不用关心代理是否存在，其代理的产生是由真实角色决定的，这样解释还是比较复杂，我们还是用实例来讲解。
&&&&& 首先说普通代理，它的要求就是客户端只能访问代理角色，而不能访问真实角色，这是比较简单的，我们以上面的例子作为扩展，我自己作为一个游戏玩家，我肯定自己不练级了，也就是场景类不能再直接new一个GamePlayer对象了，它必须由GampePlayerProxy来进行模拟场景，类图修改如图12-4所示。
图12-4 普通代理类图
&&&&& 改动很小，仅仅修改了两个实现类的构造函数，GamePlayer的构造函数增加了_gamePlayer参数，而代理角色则只要传入代理者名字即可，而不需要说是替哪个对象做代理。GamePlayer类如代码清单12-10所示。
代码清单12-10 普通代理的游戏者public class GamePlayer implements IGamePlayer {
private String name = "";
//构造函数限制谁能创建对象，并同时传递姓名
public GamePlayer(IGamePlayer _gamePlayer,String _name) throws Exception{
if(_gamePlayer == null ){
throw new Exception("不能创建真是角色！");
this.name = _
//打怪，最期望的就是杀老怪
public void killBoss() {
System.out.println(this.name + "在打怪！");
//进游戏之前你肯定要登录吧，这是一个必要条件
public void login(String user, String password) {
System.out.println("登录名为"+user + " 的用户 " + this.name + "登录成功！");
//升级，升级有很多方法，花钱买是一种，做任务也是一种
public void upgrade() {
System.out.println(this.name + " 又升了一级！");
&&&&& 在构造函数中，传递进来一个IGamePlayer对象，检查谁能创建真实的角色，当然还可以有其他的限制，比如类名必须为Proxy类等等，读者可以根据实际情况进行扩展。GamePlayerProxy如代码清单12-11所示。
代码清单12-11 普通代理的代理者public class GamePlayerProxy implements IGamePlayer {
private IGamePlayer gamePlayer =
//通过构造函数传递要对谁进行代练
public GamePlayerProxy(String name){
gamePlayer = new GamePlayer(this,name);
} catch (Exception e) {
// TODO 异常处理
//代练杀怪
public void killBoss() {
this.gamePlayer.killBoss();
//代练登录
public void login(String user, String password) {
this.gamePlayer.login(user, password);
//代练升级
public void upgrade() {
this.gamePlayer.upgrade();
&&&&& 仅仅修改了构造函数，传递进来一个代理者名称，即可进行代理，在这种改造下，系统更加简洁了，调用者只知道代理存在就可以，不用知道代理了谁。同时场景类也稍作改动，如代码清单12-12所示。
代码清单12-12 普通代理的场景类public class GamePlayerProxy implements IGamePlayer {
private IGamePlayer gamePlayer =
//通过构造函数传递要对谁进行代练
public GamePlayerProxy(String name){
gamePlayer = new GamePlayer(this,name);
} catch (Exception e) {
// TODO 异常处理
//代练杀怪
public void killBoss() {
this.gamePlayer.killBoss();
//代练登录
public void login(String user, String password) {
this.gamePlayer.login(user, password);
//代练升级
public void upgrade() {
this.gamePlayer.upgrade();
&&&&& 运行结果完全相同。在该模式下，调用者只知代理而不用知道真实的角色是谁，屏蔽了真实角色的变更对高层模块的影响，真实的主题角色爱怎么修改就怎么修改，对高层次的模块没有任何的影响，只要你实现了接口所对应的方法，该模式非常适合对扩展性要求较高的场合。当然，在实际的项目中，一般都是通过约定来禁止new一个真实的角色，也是一个非常好的方案。
&&&&& 注意 普通代理模式的约束问题，尽量通过团队内的编程规范类约束，因为每一个主题类是可被重用的和可维护的，使用技术约束的方式对系统维护是一种非常不利的因素。
12.4.2 强制代理
&&&&& 强制代理在设计模式中比较另类，为什么这么说呢？一般的思维都是通过代理找到真实的角色，但是强制代理却是要“强制”，你必须通过真实角色查找到代理角色，否则你不能访问，甭管你是通过代理类还是通过直接new一个主题角色类，都不能访问，只有通过真实角色指定的代理类才可以访问，也就是说由真实角色管理代理角色，这么说吧，高层模块new了一个真实角色的对象，返回的却是代理角色，这就好比是你和一个明星比较熟，相互认识，有件事情你需要向她确认一下，于是你就直接拨通了明星的电话：
&&&&& “喂，沙比呀，我要见一下XXX导演，你帮下忙了！”
&&&&& “不行呀衰哥，我这几天很忙呀，你找我的经纪人吧…”
&&&&& 郁闷了吧，你是想直接绕过她的代理，谁知道返回的还是她的代理，这就是强制代理，你可以不用知道代理存在，但是你的所作所为还是需要代理为你提供。我们把上面的例子稍作修改就可以完成，如图12-5所示。
图12-5 强制代理类图
&&&&& 在接口上增加了一个getProxy方法，真实角色GamePlayer可以指定一个自己的代理，除了代理外谁都不能访问。我们来看代码，先看IGamePlayer接口，如代码清单12-13所示。
代码清单12-13 强制代理的接口类public interface IGamePlayer {
//登录游戏
public void login(String user,String password);
//杀怪，这是网络游戏的主要特色
public void killBoss();
public void upgrade();
//每个人都可以找一下自己的代理
public IGamePlayer getProxy();
&&&&& 仅仅增加了一个getProxy方法，指定要访问自己必须通过哪个代理，实现类也要做适当的修改，先看真实角色GamePlayer，如代码清单12-14所示。
代码清单12-14 强制代理的真实角色public class GamePlayer implements IGamePlayer {
private String name = "";
//我的代理是谁
private IGamePlayer proxy =
public GamePlayer(String _name){
this.name = _
//找到自己的代理
public IGamePlayer getProxy(){
this.proxy = new GamePlayerProxy(this.name);
return this.
//打怪，最期望的就是杀老怪
public void killBoss() {
if(this.isProxy()){
System.out.println(this.name + "在打怪！");
System.out.println("请使用指定的代理访问");
//进游戏之前你肯定要登录吧，这是一个必要条件
public void login(String user, String password) {
if(this.isProxy()){
System.out.println("登录名为"+user + " 的用户 " + this.name + "登录成功！");
System.out.println("请使用指定的代理访问");;
//升级，升级有很多方法，花钱买是一种，做任务也是一种
public void upgrade() {
if(this.isProxy()){
System.out.println(this.name + " 又升了一级！");
System.out.println("请使用指定的代理访问");
//校验是否是代理访问
private boolean isProxy(){
if(this.proxy == null){
&&&&& 增加了一个私有方法，检查是否是自己指定的代理，是指定的代理则允许访问，否则不允许访问。我们再来看代理角色，如代码清单12-15所示。
代码清单12-15 强制代理的代理类public class GamePlayerProxy implements IGamePlayer {
private IGamePlayer gamePlayer =
//构造函数传递用户名
public GamePlayerProxy(IGamePlayer _gamePlayer){
this.gamePlayer = _gameP
//代练杀怪
public void killBoss() {
this.gamePlayer.killBoss();
//代练登录
public void login(String user, String password) {
this.gamePlayer.login(user, password);
//代练升级
public void upgrade() {
this.gamePlayer.upgrade();
//代理的代理暂时还没有,就是自己
public IGamePlayer getProxy(){
&&&&& 代理角色也可以再次被代理，这里我们就没有继续延伸下去了，查找代理的方法就返回自己的实例。代码都写完毕了，我们先按照常规的思路来运行一下，直接new一个真实角色，如代码清单12-16所示。
代码清单12-16 直接访问真实角色public class Client {
public static void main(String[] args) {
//定义个游戏的角色
IGamePlayer player = new GamePlayer("张三");
//开始打游戏，记下时间戳
System.out.println("开始时间是： 10:45");
player.login("zhangSan", "password");
//开始杀怪
player.killBoss();
player.upgrade();
//记录结束游戏时间
System.out.println("结束时间是： 03:40");
&&&&& 想想看能运行吗？运行结果如下所示：
开始时间是： 10:45
请使用指定的代理访问
请使用指定的代理访问
请使用指定的代理访问
结束时间是： 03:40
&&&&& 它要求你必须通过代理来访问，你想要直接访问它，门儿都没有，好，你要我通过代理来访问，那就生产一个代理，如代码清单12-17所示。
代码清单12-17 直接访问代理类public class Client {
public static void main(String[] args) {
//定义个游戏的角色
IGamePlayer player = new GamePlayer("张三");
//然后再定义一个代练者
IGamePlayer proxy = new GamePlayerProxy(player);
//开始打游戏，记下时间戳
System.out.println("开始时间是： 10:45");
proxy.login("zhangSan", "password");
//开始杀怪
proxy.killBoss();
proxy.upgrade();
//记录结束游戏时间
System.out.println("结束时间是： 03:40");
&&&&& 这次能访问吗？还是不行，结果如下所示：
开始时间是： 10:45
请使用指定的代理访问
请使用指定的代理访问
请使用指定的代理访问
结束时间是： 03:40
&&&&& 同样是不能访问，为什么呢？它不是真实角色指定的对象，这个代理对象是你自己new出来的，当然真实对象不认了，这就好比是那个明星，人家已经告诉你去找她的代理人了，你随便找个代理人能成吗？你必须去找她指定的代理才成！我们修改一下场景类，如代码清单12-18所示。
代码清单12-18 强制代理的场景类public class Client {
public static void main(String[] args) {
//定义个游戏的角色
IGamePlayer player = new GamePlayer("张三");
//获得指定的代理
IGamePlayer proxy = player.getProxy();
//开始打游戏，记下时间戳
System.out.println("开始时间是： 10:45");
proxy.login("zhangSan", "password");
//开始杀怪
proxy.killBoss();
proxy.upgrade();
//记录结束游戏时间
System.out.println("结束时间是： 03:40");
&&&&& 运行结果如下：
开始时间是： 10:45
登录名为zhangSan 的用户 张三登录成功！
张三在打怪！
张三 又升了一级！
结束时间是： 03:40
&&&&& OK，可以正常访问代理了。强制代理的概念就是要从真实角色查找到代理角色，不允许直接访问真实角色，高层模块只要调用getProxy就可以访问真实角色的所有方法，它根本就不需要产生一个代理出来，代理的管理已经由真实角色自己完成。
12.4.3 代理是有个性的
&&&&& 一个类可以实现多个接口，完成不同任务的整合，那也就是说代理类不仅仅可以实现主题接口，也可以实现其他接口完成不同的任务，而且代理的目的是在目标对象方法的基础上作增强，这种增强的本质通常就是对目标对象的方法进行拦截和过滤，例如游戏代理是需要收费的，升一级需要5元钱，这个计算功能就是代理类的个性，它应该在代理的接口中定义，如图12-6所示。
图12-6 代理类的个性
&&&&& 增加了一个IProxy接口，其作用是计算代理的费用，否则代理公司不是亏死了，我们先来看IProxy接口，如代码清单12-19所示。
代码清单12-19 代理类的接口public interface IProxy {
//计算费用
public void count();
&&&&& 仅仅一个方法，非常简单，看GamePlayerProxy来的变化，如代码清单12-20所示。
代码清单12-20 代理类public class GamePlayerProxy implements IGamePlayer,IProxy {
private IGamePlayer gamePlayer =
//通过构造函数传递要对谁进行代练
public GamePlayerProxy(IGamePlayer _gamePlayer){
this.gamePlayer = _gameP
//代练杀怪
public void killBoss() {
this.gamePlayer.killBoss();
//代练登录
public void login(String user, String password) {
this.gamePlayer.login(user, password);
//代练升级
public void upgrade() {
this.gamePlayer.upgrade();
this.count();
//计算费用
public void count(){
System.out.println("升级总费用是：150元");
&&&&& 实现了IProxy接口，同时在upgrade方法中调用该方法，完成费用结算，其他的类都没有任何改动，运行结果如下：
开始时间是： 10:45
登录名为zhangSan 的用户 张三登录成功！
张三在打怪！
张三 又升了一级！
升级总费用是：150元
结束时间是： 03:40
&&&&& 好了，代理公司也赚钱了，我的游戏也升级了，皆大欢喜。代理类不仅仅是都可以有自己的运算方法，通常的情况下代理的职责并不一定单一，它可以组合其他的真实角色，也可以实现自己的职责，比如计算费用。代理类可以为真实角色预处理消息、过滤消息、消息转发、事后处理消息等功能，当然一个代理类，可以代理多个真实角色，并且真实角色之间可以有耦合关系，读者可以自行扩展一下。
12.4.4 虚拟代理
&&&&& 虚拟代理(Virual Proxy)听着很复杂，其实非常简单，我们只要把代理模式的通用代码稍微修改一下就成为虚拟代理，修改后的代理类如代码清单12-21所示。
代码清单12-21 虚拟代理类public class Proxy implements Subject {
//要代理哪个实现类
//实现接口中定义的方法
public void request() {
//判断一下真实主题是否初始化
if(subject == null){
subject = new RealSubject();
subject.request();
&&&&& 在需要的时候才初始化主题对象，可以避免被代理对象较多而引起的初始化缓慢的问题，它的缺点就是需要在每个方法中判断主题对象是否被创建，这就是虚拟代理，非常简单。
12.4.5 动态代理
&&&&& 放在最后讲的一般都是压轴大戏，动态代理就是如此，上面的章节都是一个引子，动态代理才是重头戏。嘛是动态代理？动态代理是在实现阶段不用关心代理谁，而在运行阶段才指定代理那一个对象，相对的来说，自己写代理类的方式就是静态代理。本章节的核心部分就在动态代理上，现在有一个非常流行的名称叫做：面向横切面编程，也就是AOP（Aspect Oriented Programming），其核心就是采用了动态代理机制，既然这么重要，我们就来看看动态代理是如何实现的，还是以打游戏为例，类图修改一下以实现动态代理，如图12-7所示。
图12-7 动态代理
&&&&& 在类图中增加了一个InvocationHanlder接口和GamePlayIH类，作用就是产生一个对象的代理对象，其中InvocationHanlder是JDK提供的动态代理接口，对被代理类的方法进行代理。我们来看程序，接口保持不变，实现类也没有变化，请参考代码清单12-1、12-2所示。我们来看DynamicProxy类，如代码清单12-22所示。
代码清单12-22 动态代理类public class GamePlayIH implements InvocationHandler {
//被代理者
Class cls =
//被代理的实例
Object obj =
//我要代理谁
public GamePlayIH(Object _obj){
this.obj = _
//调用被代理的方法
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
Object result = method.invoke(this.obj, args);
&&&&& 其中invoke方法是接口InvocationHandler定义必须实现的，它完成对真实方法的调用。我们来详细讲解一下InvocationHanlder接口，动态代理是根据被代理的接口生成所有的方法，也就是说给定一个接口，动态代理会宣称“我已经实现该接口下的所有方法了”，那各位读者想想看，动态代理怎么才能实现被代理接口中的方法呢？默认情况下所有的方法返回值都是空的，是的，代理已经实现它了，但是没有任何的逻辑含义，那怎么办？好办，通过InvocationHandler接口，所有方法都由该Handler来进行处理，即所有被代理的方法都由InvocationHandler接管实际的处理任务。
&&&&& 我们接下来看看场景类，如代码清单12-23所示。
代码清单12-23 动态代理的场景类public class Client {
public static void main(String[] args) throws Throwable {
//定义一个痴迷的玩家
IGamePlayer player = new GamePlayer("张三");
//定义一个handler
InvocationHandler handler = new GamePlayIH(player);
//开始打游戏，记下时间戳
System.out.println("开始时间是： 10:45");
//获得类的class loader
ClassLoader cl = player.getClass().getClassLoader();
//动态产生一个代理者
IGamePlayer proxy = (IGamePlayer)Proxy.newProxyInstance(cl,new Class[]{IGamePlayer.class},handler);
proxy.login("zhangSan", "password");
//开始杀怪
proxy.killBoss();
proxy.upgrade();
//记录结束游戏时间
System.out.println("结束时间是： 03:40");
&&&&& 很奇怪是吗？不要着急，学习是一个循序渐进的过程，继续看下去，我知道你的疑惑了。其运行结果如下：
开始时间是： 10:45
登录名为zhangSan 的用户 张三登录成功！
张三在打怪！
张三 又升了一级！
结束时间是： 03:40
&&&&& 我们还是让代练者帮我们打游戏，但是我们既没有创建代理类，也没有实现IGamePlayer接口，这就是动态代理。别急，动态代理可不仅仅就这么多内容，还有更重要的，如果我们想在游戏登陆后发一个信息给我，防止账号被人盗用嘛，该怎么处理？直接修改被代理类GamePlayer？这不是一个好办法，好办法如代码清单12-24所示。
代码清单12-24 修正后的动态代理public class GamePlayIH implements InvocationHandler {
//被代理者
Class cls =
//被代理的实例
Object obj =
//我要代理谁
public GamePlayIH(Object _obj){
this.obj = _
//调用被代理的方法
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
Object result = method.invoke(this.obj, args);
//如果是登录方法，则发送信息
if(method.getName().equalsIgnoreCase("login")){
System.out.println("有人在用我的账号登陆！");
&&&&& 看黑体部分，只要在代理中增加一个判断就可以决定是否要发送信息，运行结果如下：
开始时间是： 10:45
登录名为zhangSan 的用户 张三登录成功！
有人在用我的账号登陆！
张三在打怪！
张三 又升了一级！
结束时间是： 03:40
&&&&& That’s very nice。 有人用我的账号就发送一个信息，然后看看自己的账号是不是被人盗了，非常好的方法，这就是AOP编程，AOP编程没有使用什么新的技术，但是它对我们的设计、编码有非常大的影响，对于日志、事务、权限等都可以在系统设计阶段不用考虑，而在设计后通过AOP的方式切过去。既然动态代理是如此的诱人，我们来看看通用动态代理模型，类图如图12-7所示。
图12-8 动态代理通用类图
&&&&& 很简单，两条独立发展的线路，动态代理实现代理的职责，业务逻辑Subject实现相关的逻辑功能，两者之间没有必然的相互耦合的关系，通知Advice从另一个切面切入，最终在高层模块也就是Client进行耦合，完成逻辑的封装任务，我们先来看Subject接口，如代码清单12-25所示。
代码清单12-25 抽象主题public interface Subject {
//业务操作
public void doSomething(String str);
其中的doSomething是一个标示方法，可以有多个逻辑处理方法，实现类如代码清单12-25所示。
代码清单12-26 真实主题
public class RealSubject implements Subject {
//业务操作
public void doSomething(String str) {
System.out.println("do something!----&" + str);
&&&&& 重点是我们的MyInvocationHandler，如代码清单12-27所示。
代码清单12-27 动态代理的Handler类public class MyInvocationHandler implements InvocationHandler {
//被代理的对象
private Object target =
//通过构造函数传递一个对象
public MyInvocationHandler(Object _obj){
this.target = _
//代理方法
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
//执行被代理的方法
return method.invoke(this.target, args);
&&&&& 非常简单，所有通过动态代理实现的方法全部通过invokve方法调用。DynamicProxy代码如代码清单12-28所示。
代码清单12-28 动态代理类public class DynamicProxy&T& {
public static &T& T newProxyInstance(ClassLoader loader, Class&?&[] interfaces, InvocationHandler h){
//寻找JoinPoint连接点，AOP框架使用元数据定义
//执行一个前置通知
(new BeforeAdvice()).exec();
//执行目标，并返回结果
return (T)Proxy.newProxyInstance(loader,interfaces, h);
&&&&& 在这里插入了较多的AOP术语，在什么地方（连接点）执行什么行为（通知），我们在这里实现了一个简单的横切面编程，读者有经验的话可以看看AOP的配置文件就会明白这段代码的意义了。我们来看通知Advice，也就是我们要切入的类，比较简单，接口和实现如代码清单12-29所示。
代码清单12-29 通知接口及实现public interface IAdvice {
//通知只有一个方法，执行即可
public void exec();
public class BeforeAdvice implements IAdvice{
public void exec(){
System.out.println("我是前置通知，我被执行了！");
&&&&& 最后就是看我们怎么调用了，如代码清单12-30所示。
代码清单12-30 动态代理的场景类public class Client {
public static void main(String[] args) {
//定义一个主题
Subject subject = new RealSubject();
//定义一个Handler
InvocationHandler handler = new MyInvocationHandler(subject);
//定义主题的代理
Subject proxy = DynamicProxy.newProxyInstance(subject.getClass().getClassLoader(), subject.getClass().getInterfaces(),handler);
//代理的行为
proxy.doSomething("Finish");
&&&&& 运行结果如下所示：
我是前置通知，我被执行了！
do something!----&Finish
&&&&& 好，所有的程序都看完了，我们回过头来看看程序是怎么实现的。在DynamicProxy类中，我们有这样的方法：
&&&&& this.obj = Proxy.newProxyInstance(c.getClassLoader(), c.getInterfaces(), new MyInvocationHandler(_obj));
&&&&& 该方法是重新生成了一个对象，为什么要重新生成？你要使用代理呀，注意c.getInterfaces()这句话，这是非常有意思的一句话，是说查找到该类的所有接口，然后实现接口的所有方法，当然了，方法都是空的，由谁具体负责接管呢？是new MyInvocationHandler(_Obj)这个对象，于是清楚了：一个类的动态代理类是这样的一个类，由InvocationHandler的实现类实现所有的方法，由其invoke方法接管所有方法的实现，其动态调用过程如图12-9所示。
图12-9 动态代理调用过程示意图
&&&&& 读者可能注意到我们以上的代码还有更进一步的扩展余地，那当然了，注意看DynamicProxy类，它是一个通用类，不具有业务意义，如果我们再产生一个实现类是不是就很有意义了呢？如代码清单12-31所示。
代码清单12-31 具体业务的动态代理public class SubjectDynamicProxy extends DynamicProxy{
public static &T& T newProxyInstance(Subject subject){
//获得ClassLoader
ClassLoader loader = subject.getClass().getClassLoader();
//获得接口数组
Class&?&[] classes = subject.getClass().getInterfaces();
//获得handler
InvocationHandler handler = new MyInvocationHandler(subject);
return newProxyInstance(loader, classes, handler);
&&&&& 如此扩展以后，高层模块对代理的访问会更加简单，如代码清单12-32所示。
代码清单12-32 场景类public class Client {
public static void main(String[] args) {
//定义一个主题
Subject subject = new RealSubject();
//定义主题的代理
Subject proxy = SubjectDynamicProxy.newProxyInstance(subject);
//代理的行为
proxy.doSomething("Finish");
&&&&& 是不是更加简单了？可能读者就要提问了，这样与静态代理还有什么区别？都是需要实现一个代理类，有区别，注意看父类，动态代理的主要意图就是解决我们常说的“审计”问题，也就横切面编程，在不改变我们已有代码结构的情况下增强或控制对象的行为。
&&&&& 注意 要实现动态代理的首要条件是：被代理类必须实现一个接口，回想一下刚刚的分析吧。当然了，现在也有很多技术如CGLIB可以实现不需要接口也可以实现动态代理的方式。
&&&&& 再次说明，以上的动态代理是一个通用代理框架，如果你想设计自己的AOP框架，完全可以在此基础上扩展，我们设计的是一个通用代理，只要有一个接口，一个实现类，就可以使用该代理，完成代理的所有功效。
12.5 最佳实践
&&&&& 代理模式应用的非常广泛，大到一个系统框架、企业平台，小到代码片段、事务处理，稍不留意就用到代理模式，可能该模式是大家接触最多的模式，而且有了AOP大家写代理就更加简单了，有类似Spring AOP和AspectJ这样非常优秀的工具，拿来主义即可，我们还自己写代理干嘛！不过，大家可以看看源代码，特别是调试时，只要看到类似$Proxy0这样的结构，你就应该知道这是一个动态代理了。
友情提醒，在学习AOP框架时，弄起初几个名词就成：切面（Aspect）、切入点(JoinPoint)、通知（Advice）、织入（Weave）就足够了，理解了这几个名词，你就可以对AOP游刃有余了！
评论 - 202