学习IOC和AOP的一点收获

所有编程中的方法，最终目的是解耦，这句话不是我原产的，但是我目前也强烈地这么认为。解耦的目的是为什么呢？或者说解耦后的代码有什么优势呢？当各个类或者各个函数的目的（或者叫关注点）都很单纯的时候，系统后期的升级，测试都变得相对容易了。这样，系统的寿命延长，系统的缺陷可以很快得到解决，还有什么比这些优点更臭屁的呢？

Spring中的IOC(inversion of control)，我觉得是一个相当令人惊叹地做法。在没有IOC的时候，一个对象想要调用另一个对象的方法，那必须要知道这个对象，它什么时候调用，如何调用，都是它说了算，但是有了IOC之后，这些控制权都交给了容器，所以我觉得IOC叫成反转控制似乎不妥。反转控制字面上应该是这样的，例如以前是他控制她，现在成了她控制他。而IOC感觉是现在他俩谁也没控制谁，都被别人控制了，不知道我这个理解是否正点。

AOP这个东西也着实让我费了点学习功夫，现在看来是这样的。AOP的出现肯定是为了解决一些问题的，照应开头一句，为了解耦。解谁和谁的耦？在没有AOP之前，主要业务逻辑代码周围会有很多次要的、支持性质的代码，例如log、事务和检查等功能，这显然是不理想的代码，如果事务的逻辑要改怎么办，检查的逻辑要改怎么办，AOP的出现就是把这些次要的、支持性的代码模块化，封装起来。

IOC和AOP是相互配合的，只有把控制权交给容器，AOP才能发挥作用。