java Proxy和rtti(反射)实现动态代理工厂.docVIP

java 反射实现动态代理工厂 Proxy 场景 有个类【大排档】（Stall），它有个方法“提供饭菜”（providedMeals），就是“来吃饭” 有个类【饭馆】（Restaurant），它有个方法“提供饭菜”（providedMeals） 这两个类有个特点，都是提供吃饭的地方，都有相同的方法“提供饭菜”（providedMeals）。那可以定义一个接口【提供吃的地方】（ProvidedEatOfLocal），它有个抽象方法“提供饭菜”（providedMeals）。用这两个类去实现这个接口。 不管是【大排档】还是【饭馆】，在“提供饭菜”（providedMeals）前要做“点餐”（ordering）的工作，之后要做“埋单”（payMoney）的工作。 那我们在实现【大排档】和【饭馆】的“提供饭菜”（providedMeals）方法时，把这“点餐”（ordering）和“埋单”（payMoney）的代码加在一前一后就可以啦。 问题 但这是重复代码，如果“点餐”的流程发生了改变（比如从人工点餐变成了机器点餐），那每个实现类的方法实现里面都需要改源代码。 现在只有两个实现类，如果现在又新出现个【大酒店】（GrandHotel）类，它也有个方法“提供饭菜”（providedMeals），它也实现接口【提供吃的地方】（ProvidedEatOfLocal）。以后有更多的类都来实现这个接口。实现类越多，那“提供饭菜”（providedMeals）方法的前后工作一发生改变，那修改的类就会越多。这在设计上是不合理的。 解决方案 我们可以考虑代理模式。 我们创建一个代理人【吃货经纪人】（FoodGoodsBroker）。 【吃货经纪人】可以代理所有【提供吃的地方】的实现类，我们只要有和【吃货经纪人】打交道，从他这里我们可以得到我们吃饭的地方去吃饭。吃饭前后的统一动作（【点餐】、【埋单】）这个【吃货经纪人】会处理，实际用餐的人可以不关心啦（难道这就是传说中的吃霸王餐，不给钱？）。 所有实现了【提供吃的地方】的实现类都和【吃货经纪人】打交道，把吃饭前后的统一动作（【点餐】、【埋单】）交给【吃货经纪人】会处理。【点餐】和【埋单】的行为如果有变化就统一变化。如果新来个【提供吃的地方】的实现类也想这么处理，那它也和【吃货经纪人】打交道。 如上所述，实际使用者（用餐的人）是不去关心各种饭店的具体各种的。而新来的饭店如果可要照这么做，也只要和【吃货经纪人】打交道，就能做到统一处理。而这些统一处理的地方如果方法改变，那就都改变，不要去修改每个实现类的具体方法。 这样最累的就是【吃货经纪人】。而提供者（实现了【提供吃的地方】的实现类）和使用者是完全脱离的。完全符合软件设计的开闭原则。 是不是很一横一撇一捺，外带四把X！！！ 另外一个场景也能说明这个问题 数据库的操作有增、删、改、查 在做这四个操作前都要开打一个数据库连接 做完操作后都要关闭这个连接 如果开连接和关连接的代码发生改变，那很多的地方都要改变 这时可以用代理，统一处理这些工作 1----ProvidedEatOfLocal.java package com.luo.rtti.proxy3; // 定义接口 -- 提供吃饭的地方 public interface ProvidedEatOfLocal { // 抽象方法 -- 提供饭菜 void providedMeals(); } Stall.java package com.luo.rtti.proxy3; // 定义实现类 -- 大排档 实现 提供吃饭的地方 public class Stall implements ProvidedEatOfLocal { // 地方的名字 String local_name = 胖哥大排档; // 实现方法 -- 提供饭菜 public void providedMeals() { System.out.println(马路边...塑料凳...烧烤...砂锅粥...诸葛烤鱼...还有很多吃的...小龙虾); } } Restaurant.java package com.luo.rtti.proxy3; //定义实现类 -- 饭馆 实现 提供吃饭的地方 public class Restaurant implements ProvidedEatOfLocal { // 地方的名字 String local_name = 湘粤情饭馆; // 实现方法 -- 提供饭菜 public void providedMeals() { System.out.pri