1. Public class ViewAction implements Action
2. {
3. public void doAction()
4. {
5. //做View的动作
6. System.out.println(“You could view the information……”);
7. ……
8. }
9. }
代 理的意思很好理解,它借鉴了我们日常所用的代理的意思:就是本来该自己亲自去做的某件事,由于某种原因不能直接做,而只能请人代替你做,这个被你请来做事 的人就是代理。比如过春节要回家,由于你要上班,没时间去买票,就得票务中介代你购买,这就是一种代理模式。这个情景可以形象的描述如下:
1. class:火车站
2. {
3. 卖票:
4. {……}
5. }
火车站是卖票的地方,我们假设只能在火车站买到票。卖票的动作实质是火车站类完成的。
1. Class:票务中介
2. {
3. 卖票:
4. {
5. 收中介费;
6. 火车站.卖票;
7. }
8. }
顾客找票务中介买票的时候,调用票务中介.卖票。票务中介其实做了两件事,一是去火车站买票,二是不能白帮你卖票,肯定要收中介费。而你得到的好处是不用直接去火车站买票,节省了买票的时间用来上班。
以上我们简单模拟了代理模式的情景和为什么要使用代理模式,下面我们以一个例子来具体分析一下JAVA中的代理模式。
假设有一个信息管理系统,用些用户有浏览信息的权限,有些用户有浏览、添加和修改信息的权限,还有些用户有除了上述的权限,还有删除信息的权限,那么我们最容易想到的做法如下:
其他的动作都和浏览信息的动作差不多。我们来看这样的类,很容易看出它的一些缺点来:第一、它把权限计算和动作执行都放在一个类里,两者的功能相互混在一起,容易造成思路的混乱,而且修改维护和测试都不好;一句话来说,
它不满足单一职责原则
。第二是客户调用的时候
依赖具体的类,造成扩展和运行期内的调用的困难,不满足依赖颠倒原则
(
依赖倒转原则(DIP)尽量依赖
于
抽象,
定义一个接口去实现它,
不要依赖
于
具体
)
。
1. public class ViewAction
2. {
3. //由userId计算权限
4. ……
5. String permission = ……;
6. if(permission.equals(Constants.VIEW))
7. {
8. System.out.println(“You could view the information……”);
9. ……
10. }
11. }
既然有这么多的问题,我们有必要对该类进行重新设计。其实大家早已想到,这个类应该使用代理模式。是啊,和我们买火车票的动作一样,动作类不能直接执行那个动作,而是要先检查权限,然后才能执行;先检查权限,后执行的那各类其实就是一个代理类,修改后的代码如下:
1. public interface Action
2. {
3. public void doAction();
4. }
首先是设计一个接口,用来满足依赖颠倒原则。
这个类跟火车站一样,是动作的真实执行者。
1. Public class ViewAction implements Action
2. {
3. public void doAction()
4. {
5. //做View的动作
6. System.out.println(“You could view the information……”);
7. ……
8. }
9. }
1. Public class ProxyViewAction implements Action
2. {
3. private Action action = new ViewAction();
4. public void doAction()
5. {
6. //调用权限类的方法取得用户权限
7. if(Permission.getPermission(userId).equals(Constants.VIEW))
8. {
9. action.doAction();
10. }
11. }
12. }
这是代理类,很容易理解。在我们的ProxyViewAction类中,除了做了客户真正想要做的动作:doAction()以外,还进行了
额外
的动作检查用户的权限。而作核心动作doAction()是在一个
干干净净
的类:ViewAction中进行,这个类只做
核心动作
,对其他的不关心,满足了单一职责原则。
客户端通过调用代理类来执行动作
,而代理类一是将权限判断和动作的执行分离开来,满足了单一职责原则;二是实现了
同
一个接口,从而满足了依赖颠倒原则。比第一个思路好了很多。
代理又被称为
委派
,说的是代理类
并不真正的执行那个核心动作
,而是委派给另外一个类去执行,如ProxyView类中,ProxyView类并没有真正执行doAction()方法,而是交给ViewAction类去执行。
我 们再来看代理类ProxyViewAction,可以看到它不仅依赖于接口Action,而且依赖于具体的实现ViewAction。这样对我们的系统扩 展很不利,比如我们有Add动作、Delete动作、Modify动作等等,我们需要对每一个动作都写一个代理类,而这些代理类都做同样的事情,先进行权 限判断,然后再委派。所以我们需要对这些代理再进行一次抽象,
让它只依赖接口Action,而不依赖于具体的实现
。
要实现这样的想法,我们需要将代理类中的具体实现提走,让代理的使用者在运行期提供具体的实现类,即所谓的 依赖注入 ,如下:
1. Public class ProxyAction implements Action
2. {
3. private Action action;
4. public ProxyAction(Action action)
5. {
6. this.action = action;
7. }
8. public void doAction()
9. {
10. //调用权限类的方法取得用户权限
11. if(Permission.getPermission(userId).equals(action.getClass().getName()))
12. {
13. action.doAction();
14. }
15. }
16. }
这样,我们就将所有实现了Action接口的实现使用一个代理类来代理它们。除了ViewAction类能用,以后扩展的AddAction、 ModifyAction、DeleteAction类等等,都可以使用一个代理类:ProxyAction。
而我们的客户端类似如下:
Action action = ProxyAction(new ViewAction);
Action.doAction();
通过对代理类的
依赖注入
, 我们使得代理类初步有了一定扩展性。但是我们还要看到,这个代理类依赖于某一个确定的接口。这仍然不能满足我们的实际要求,如我们的系统的权限控制一般是 整个系统级的,这样系统级的权限控制,我们很难在整个系统里抽象出一个统一的接口,可能会有多个接口,按照上面的代理模式,我们需要对每一个接口写一个代 理类,同样,这些类的功能都是一样的。这显然不是一个好地解决办法。
基于上面的原因,我们需要解决一个系统在没有统一的接口的情况下,对一些零散的对象的某一些动作使用代理模式的问题。JAVA API为我们引入了动态代理或动态委派的技术。
动态代理的核心是
InvocationHandler接口
,要使用动态代理就必须实现该接口。这个接口的委派任务是在invoke(Object proxy, Method m, Object[] args)方法里面实现的:
//invoke是调用的意思
//在调用核心功能之前作一些动作
……
//调用核心功能
m.invoke(obj, args);
//在调用核心功能以后做一些动作
……
我们可以看到动态代理其实用的是
反射机制
来调用核心功能的:m.invoke(obj, args);正是这种反射机制的使用使得我们调用核心功能更加灵活,而
不用依赖于某一个具体的接口,而是依赖于Object对象
。
下面我们来具体看看动态代理或动态委派如何使用:
1. public class ProxyAction implements InvocationHandler {
2. private Object action;
3. //构造方法
4. public ProxyAction(Object action)
5. {
6. this.action = action;
7. }
8. public static Object getInstance(Object action)
9. {
10. return Proxy.newProxyInstance(action.getClass().getClassLoader(),
11. action.getClass().getInterfaces(),new ProxyAction(action));
12. }
13.
14. public Object invoke(Object proxy, Method m, Object[] args)
15. throws Throwable {
16.
17. Object result;
18.
19. try {
20. //在委派之前作动作,如权限判断等
21. System.out.println("before method " + m.getName());
22. //进行委派
23. result = m.invoke(action, args);
24.
25. } catch (InvocationTargetException e) {
26.
27. throw e.getTargetException();
28.
29. } catch (Exception e) {
30.
31. throw new RuntimeException("unexpected invocation exception: "
32.
33. + e.getMessage());
34.
35. } finally {
36. //在委派之后做动作
37. System.out.println("after method " + m.getName());
38.
39. }
40.
41. return result;
42.
43.
44. }
45.
46. }
这个代理类,首先是实现了InvocationHandler接口;然后在getInstance()方法里得到了代理类的实例;在invoke()方法里实现代理功能,也很简单。
下面我们来看客户端:
Action action = (Action)ProxyAction.getInstance(new ViewAction());
Action.doAction();
我们可以看到代理类对接口的依赖也转移到了客户端上,这样,代理类不依赖于某个接口。对于同样的代理类ProxyAction,我们也可以有如下的客户端调用:
Engine engine = (Engine)ProxyAction.getInstance(new EngineImpl());
Engine.execute();
只要engineImpl类实现了Engine接口,就可以像上面那样使用。
现 在我们可以看到,动态代理的确是拥有相当的灵活性。但我们同时也看到了,这个代理类写起来比较麻烦,而且也差不多每次都写这样千篇一律的东西,只有委派前 的动作和委派后的动作在不同的代理里有着不同,其他的东西都需要照写。如果这样的代理类写多了,也会有一些冗余代理。需要我们进一步优化,这里我们使用模 板方法模式来对这个代理类进行优化,如下:
1. public abstract class BaseProxy implements InvocationHandler {
2. private Object obj;
3. protected BaseProxy(Object obj)
4. {
5. this.obj = obj;
6. }
7. public static Object getInstance(Object obj,InvocationHandler instance)
8. {
9. return Proxy.newProxyInstance(obj.getClass().getClassLoader(),
10. obj.getClass().getInterfaces(),instance);
11. }
12.
13. public Object invoke(Object proxy, Method m, Object[] args)
14. throws Throwable {
15. // TODO Auto-generated method stub
16. Object result;
17.
18. try {
19.
20. System.out.println("before method " + m.getName());
21. this.doBegin();
22.
23. result = m.invoke(obj, args);
24.
25. } catch (InvocationTargetException e) {
26.
27. throw e.getTargetException();
28.
29. } catch (Exception e) {
30.
31. throw new RuntimeException("unexpected invocation exception: "
32.
33. + e.getMessage());
34.
35. } finally {
36.
37. System.out.println("after method " + m.getName());
38. this.doAfter();
39.
40. }
41.
42. return result;
43.
44.
45. }
46. public abstract void doBegin();
47. public abstract void doAfter();
48.
49. }
这样,代理的实现类只需要关注实现委派前的动作和委派后的动作就行,如下
1. public class ProxyImpl extends BaseProxy {
2. protected ProxyImpl(Object o)
3. {
4. super(o);
5. }
6. public static Object getInstance(Object foo)
7. {
8. return getInstance(foo,new ProxyImpl(foo));
9. }
10.
11. //委派前的动作
12. public void doBegin() {
13. // TODO Auto-generated method stub
14. System.out.println("begin doing....haha");
15.
16. }
17.
18. //委派后的动作
19. public void doAfter() {
20. // TODO Auto-generated method stub
21. System.out.println("after doing.....yeah");
22.
23. }
24.
25. }
从上面的代码,我们可以看出代理实现类的确是简单多了,只关注了委派前和委派后的动作,这是我们作为一个代理真正需要关心的。
至此,代理模式和动态代理已经告一段落。我们将动态代理引申一点说开去,来作为这篇文章的蛇足。
这 个话题就是面向方面的编程,或者说AOP。我们看上面的ProxyImpl类,它的两个方法doBegin()和doAfter(),这是做核心动作之前 和之后的两个截取段。正是这两个截取段,却是我们AOP的基础。在OOP里,doBegin(),核心动作,doAfter()这三个动作在多个类里始终 在一起,但他们所要完成的逻辑却是不同的,如doBegin()可能做的是权限,在所有的类里它都做权限;而在每个类里核心动作却各不相 同;doAfter()可能做的是日志,在所有的类里它都做日志。正是因为在所有的类里,doBegin()或doAfter()都做的是同样的逻辑,因 此我们需要将它们提取出来,单独分析、设计和编码,这就是我们的AOP的思想。
这样说来,我们的动态代理就能作为实现AOP的基础了。好了,就说这么多,关于AOP技术,我们可以去关注关于这方面的知识。