DesignPattern- 代理模式

代理模式，应该是我在工作中用的最多的一种设计模式了。

 个人觉的这种设计模式能比较好的解耦和，特别是业务比较复杂的情况下。

     之前重构过这样一个系统，经过分解他有几大模块组成。

      我在接手这个项目的时候，它的代码完全已经在逻辑之外了。公司先后进来几个新人都跟我反馈，代码写的太难懂了。因为项目是由我来负责，老大那边直接来找我，再加上后来的bug已经多的不能修了，所以硬着头皮给重写了一下。用到了分层思想，MVC模式，回头来看，里面代码最有韵味的是代理模式了。

    在接触代理模式的时候，我记得曾经看过一句话，代理模式可以对真正的行为进行拦截。拦截这词用的比较专业，其实可以直接理解在调用真正行为的时候再加上一层逻辑，这里的逻辑可能就是你的业务了

    先上一张图：

            

 

 

  

  上代码：

      IAction:     

package com.jerome.designpattern.proxy;public interface IAction {/** * 根据actionId来执行对应的action. * @param actionId */public void doAction(int actionId);}

 

ActionProcessor:

package com.jerome.designpattern.proxy;public class ActionProcessor implements IAction {@Overridepublic void doAction(int actionId) {// TODO Auto-generated method stub//doaction......switch(actionId) {}}}

 

ActionProxy:

 

package com.jerome.designpattern.proxy;public class ActionProxy implements IAction {private IAction mActionProcessor ;public ActionProxy(IAction actionProcessor) {mActionProcessor = actionProcessor ;}@Overridepublic void doAction(int actionId) {// TODO Auto-generated method stub///////////////////////////////交付真正处理之前先预处理一下,这里一般跟软件的业务逻辑有一定的关系/////////////////////////////mActionProcessor.doAction(actionId);}}

 

     具体来说说在实践中是如何运用这种模式的。按照正常的逻辑，显示模块只负责显示，语音识别模块专门用于语音识别，播报模块只用来播报。首先对单个的模块定义好一系列接口，然后交由不同的开发来写实现。

   但是，一个系统并不是单单由独立的模块组成的，各个独立的模块组合进去，然后加上行业的业务逻辑就形成了一个软件。那我们这里的业务就是

   1.语音识别过程中停止正在播放音乐，语音识别结束开启被暂停的音乐

   2.语音识别过程中停止播报

   3.点击开始播报，若处在语音识别过程中终止本次语音识别

   .

   .

   .

   .

   这里的模块之间是有一系列的交互的。那么按照代理模式的特点来看，就跟 “拦截”有了一系列的关系，因为在单纯的做某一模块的事情之前，你需要处理本模块跟其他模块的交互（单纯的做语音识别之前，你需要暂停音乐模块的播放事件）。

 

   其实代理模式的一个最要的玩点就在于这个所谓的“拦截”。