标签：java   aop   架构   解密   

        上篇博客中，提出，优化是个无止境的过程，的确，随着需求的变化，软硬件基础的升级，我们越来越不考虑代码的容量，而是考虑代码的质量，但是随着研究的深入，到了某个阶段，我们也要考虑代码的容量问题，这时，容器的概念，脱颖而出，在上篇博客将服务类作为一个接口传入，实际在后台是一个map容器，我们不仅包含了map的全部实现，还实现了服务类的叠加，但是美中不足的是，我们的业务类，还是单个的对象，就如下图：

类图改造

       这时，我们如果想为更多的业务提供服务，就必须编写更多的aop，这不符合我们的原则，基于这一点，我做了以下的调整，大家先看类图：

        1.1，回顾上个版本类图：

         1.2，改造后的类图：

代码实现：

        我们将业务类做成了容器，然后代理类持有这个容器，这个容器的所有子元素，通过遍历，就都拥有了服务类的所有方法：

        2.1，业务容器：

<pre name="code" class="java"><span style="font-size:18px;">/**
 * 业务类容器：
 * 	用map盛放要切入服务的业务类
 *
 * @author 许恕
 * @version 3.0.0 , 2015年6月16日 下午4:41:28
 */
public class DoMehds  implements IDoMehds {
	//盛放执行业务的map
	private  HashMap<String,Object> DoBeans;

	//获取业务map
	public HashMap<String, Object> getDoBeans() {
		return DoBeans;
	}

	//设置业务map
	public void setDoBeans(HashMap<String, Object> doBeans) {
		DoBeans = doBeans;
	}
        
}
</span>

        2.2，代理类变化：

<span style="font-size:18px;"></span><pre name="code" class="java"><span style="font-size:18px;">/**
 * 打招呼动态代理类，给业务类添加功能
 * 前一版本为JDK代理实现
 * 	本次添加执行方法之前打印到控制台‘befor’
 * 	本次添加执行方法之后打印到控制台‘after’
 *本次版本为DGLIB代理
 *	换代理类原因，JDK代理要求被代理类必须实现某接口，因为它底层实现是新建一个类，实现和被代理类相同的接口
 *	用代理类新建的业务类代替原业务类
 *	CGLIB代理是新建一个类，继承自被代理类，用新建的代理类替换掉原业务类，就不需要接口了
 *
 *5.0版本增加服务组装容器，将服务从代理类中抽离出去了，我们的代理类成为了一个bean
 *6.0将服务容器定义为接口
 *7.0增加业务容器
 * @author 许恕
 * @version 3.0.0 , 2015年6月16日 下午3:20:13
 */
public class CGLibDynamicProxy implements MethodInterceptor {  
 
	//服务类容器
	private IProxyMehds proxyMehds;
	//业务类容器
    private DoMehds doMehds;
  //代理工厂类：单例模式，优化内存开销
    private static CGLibDynamicProxy instance = new CGLibDynamicProxy();  
 
    //构造函数
    private CGLibDynamicProxy() {  
    }  
 
    //获取cglib代理工厂类
    public static CGLibDynamicProxy getInstance() {  
        return instance;  
    }  
 
    /**
     * 使用代理工厂生成某个类的代理
     *
     * @param cls 要代理的类
     * @return 返回已经代理好的类
     */
    @SuppressWarnings("unchecked")  
    public <T> T getProxy(Class<T> cls) {  
        return (T) Enhancer.create(cls, this);  
    }  
 
    //获取业务容器
    private void getProxyToDoMap(){
    	
    	//从业务容器中获取业务map
    	HashMap<String,Object> mapDo = doMehds.getDoBeans();
    	
    	//循环给业务map中的业务类增加代理
    	for (HashMap.Entry<String, Object> entry : mapDo.entrySet()) {
    		
    		//获取map中的对象
    	    String objectKey = entry.getKey();
    	    Object objectValure = entry.getValue();
    	    
    	    //重新更新map中的对象：代替原业务方法
    	    mapDo.put(objectKey, getProxy(objectValure.getClass()));
    	}
    	
    }
    
    //重写被代理对象的方法执行
    //所有的方法执行，到反射的级别都是invoke，重写了这个方法，就重写了所有的方法执行，实现了代理
    @Override 
    public Object intercept(Object target, Method method, Object[] args, MethodProxy proxy) throws Throwable {  
    	//重要改进：从服务容器中执行方法，不再是写死的！
    	proxyMehds.beforeBean(); 
    	
    	//方法正常执行的语句
        Object result = proxy.invokeSuper(target, args);
        
        //重要改进：从服务容器中执行方法，不再是写死的！
        proxyMehds.afterBean(); 
        
        
        return result;   
    }

    //服务容器的get方法
	public IProxyMehds getProxyMehds() {
		return proxyMehds;
	}

	//服务容器的set方法
	public void setProxyMehds(IProxyMehds proxyMehds) {
		this.proxyMehds = proxyMehds;
	}

	//业务容器get方法
	public DoMehds getDoMehds() {
		return doMehds;
	}

	//业务容器set方法
	public void setDoMehds(DoMehds doMehds) {
		this.doMehds = doMehds;
		getProxyToDoMap();
	}  
 
    
    
}</span>

总结：

        任何事物，都是有个诞生发展的过程，人类至今发明的东西，都是来自于人类自己的生活，在学习的过程中，想象生活，我们有时候，就会豁然开朗，举个例子：

        小明要有个快递要给小李邮过去，小明找到邮递员，签字完成，过了3天小李收到了，邮递的过程就好像咱们的aop一般，对用户来说是透明的，拆箱和装箱的过程，交给各自自己负责就好，这不就是面向对象吗！

        当然，优化如此就完美了吗？当然没有，下篇博客，咱们继续对aop做深入的了解和优化！

java架构解密——双容器优化aop

标签：java   aop   架构   解密   

原文地址：http://blog.csdn.net/xvshu/article/details/46634737