从代理模式到IOC/AOP

业务代理模式，也成为代理者模式。它的核心思想即使用一个通用接口包装一个功能接口，这样，外部访问此功能时，可以在通用接口的代理这里先预处理一部分内容，然后再去执行功能接口。

如果是一个通用接口对一个功能接口，那么这是代理者模式，如果是一个通用接口对应N个功能接口，那么就比较像工厂模式了。工厂模式的优缺点也很明显，优点一是通用接口单一便于权限管理。优点二则是实现代码简洁，易于更换。但是，缺点也有两个，一个是实现的子类过多，扩展性不是很强。二是使用静态或者单态模式，容易走单线程，性能不高。

为此，才有了工厂模式的改进版本——Command模式，也就是命令模式。但是命令模式虽然克服了工厂模式入口单一的缺点，但是可控性不强，代码实现也较为多样复杂，因此，java采用的也并非是这种模式。

EJB采用的是直接调用的模式，类似命令模式，但是对于命令模式可控性差，EJB则用配置文件完善这些缺陷。

那么一个代理模式具有良好性能的指标有哪些呢？

1、  业务层所有服务都对客户端展示，也就是说客户端可以自由调用业务层的所有服务。

2、  动态扩展性强，可以动态扩展业务层的新功能。

3、  客户端调用业务层服务时，使用的代码必须简洁，至少是可配置的，最大程度减少代码的耦合性。

如果想要具备以上3点，就需要IOC模式/AOP来实现了。那么，IOC模式和AOP是什么，我们接下来再讲。

所谓的IOC模式，全称是Inversion of Control，直译过来也就是反转控制，不过平时喜欢称之为“依赖注入”。这种奇怪的叫法是有来由的，它最初的功能就是为了把耦合的代码移到配置文件XML中，这样，整个代码就具有可配置性，就可以降低代码之间的耦合性。但是配置之后，需要一个容器把配置文件里的内容和代码联系起来，这样的功能，就是所谓的框架帮我们做好的事情。

IOC其实是很神奇的东西，最基本的就是“反射编程”，当然，反射编程看起来好像不是那么高大上，但是如果说，它就是所谓的用代码来写代码，你是不是就觉得神奇了呢？反射编程，就是把我们常规编程反过来，正常情况下，我们的代码是死的，是程序员写好的，但是，一旦有了反射编程，那么代码就活了过来，这不仅仅是赋予了代码“灵魂”，而且可以让代码的“肉体”也可以随机应变。学术上来讲，反射编程就是可以动态的创建对象，通过XML配置文件，我们就可以在死的代码里，灵活的改变各种依赖关系，创建出不同的对象。如果你想象不出来，那就想象成USB接口和SCIS硬盘。

另外，在这要提一下接口，接口更像是一种类，而这种类具有一定的特殊性，这个在前面我们讲过，而IOC则更多的是依靠接口，而不是类，当然它也可以用类，但更多情况下，我们使用接口来进行反射编程，其实是很神奇的。

那么IOC模式，又称为“依赖注入”的东西，怎么注入呢，主要包括三种方式:构造注入，Setter注入以及注解注入。

所谓的构造注入，也就是指在类进行构造的时候，把对象注入进来，这样，就可以很巧妙地省略一句话，23333。所谓的Setter注入，也称为注值注入，是一个较为常见的注入方式，它是指依靠Getter,Setter来进行注入，这样的话，可以灵活的掌握注入的时机，虽然是Java用的是Setter，但是我更熟悉C#的Setter。另外，这里争议比较大的是，还有一种方式称为接口注入，实现起来和设值注入有相似之处，不过我认为接口注入式可以多个类同时依靠同一个接口注入各自的对象，而Setter则是每一个类所依靠的同名的接口，但是在参数上，有所区别。最后一个是注解注入，注解注入的使用则十分规范，主要依靠：Autowired、Resource、Qualifier、Service、Controller、Repository、Component等关键字进行注解。针对以上关键字，做以下说明：

Autowired：是自动注入，自动从spring的上下文找到合适的bean来注入。

Resource：用来指定名称注入。

Qualifier：和Autowired配合使用，指定bean的名称。

Service，Controller，Repository：分别标记类是Service层类，Controller层类，数据存储层的类，spring扫描注解配置时，会标记这些类要生成bean。

Component：是一种泛指，标记类是组件，spring扫描注解配置时，会标记这些类要生成bean。

Autowired和Resource是用来修饰字段，构造函数，或者设置方法，并做注入的，而Service，Controller，Repository，Component则是用来修饰类，标记这些类要生成bean。

以上三种的代码也较为常见，在此不做具体说明。

 

还有另外一个单词AOP，它的全称是Aspect OrientedProgramming。也就是大神们所说的面向切面编程。那么它的作用是什么？它为什么又要和IOC一起说呢？

首先，面向切面编程是面向对象编程的延续，也是目前最热的函数式编程的一种衍生泛型，它的主要目的是把业务逻辑逐层切开，如果说面向对象编程是把东西打包好成一包一包规整的箱子来运输，那么面向切面的编程就是一个又一个转运和检查。

说的这么玄乎，那么它最常用的地方在哪里呢？我们来一个情景，比如我们登陆一个网站，那么每跳转一个页面，或者没执行一个行为，都要有权限判断，或者日志记录等等。那么这些当然可以写到每一个页面，但是这样岂不是太复杂了？那么面向切面编程就解决这个问题。但是光把这些作为接口放到所要实现的类里，根本无从获知上下文啊，也就是说，实现AOP的结构容易，但是想让它活起来，光靠它自己是不够的，这就要用到IOC，通过IOC就可以轻易的获取到上下文。然后获取到上下文后，我们就可以通过传参，让AOP那些嵌入到过程里的这些函数知道自己该做些什么。这里提一句，曾经不知道安卓的框架是多么的优秀和复杂，只会照着敲，后来才知道，那些看不懂的上下文、工厂以及实现所蕴含的信息量是这么巨大。

 

通过上面的一些高级编程技巧，这些代码便不再是死的，而是活的，不仅仅具有灵魂，还有可以变化的肉体，使得程序真的开始诡异和难测起来了。