1、控制反转（IOC）
要了解控制反转( Inversion of Control ), 我觉得有必要先了解软件设计的一个重要思想：依赖倒置原则（Dependency Inversion Principle ）。
场景：
假设我们设计一辆汽车：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。
这样的设计看起来没问题，但是可维护性却很低。假设设计完工之后，上司却突然说根据市场需求的变动，要我们把车子的轮子设计都改大一码。这下我们就蛋疼了：因为我们是根据轮子的尺寸设计的底盘，轮子的尺寸一改，底盘的设计就得修改；同样因为我们是根据底盘设计的车身，那么车身也得改，同理汽车设计也得改——整个设计几乎都得改！我们现在换一种思路。我们先设计汽车的大概样子，然后根据汽车的样子来设计车身，根据车身来设计底盘，最后根据底盘来设计轮子。这时候，依赖关系就倒置过来了：轮子依赖底盘， 底盘依赖车身， 车身依赖汽车。
这时候，上司再说要改动轮子的设计，我们就只需要改动轮子的设计，而不需要动底盘，车身，汽车的设计了，这就是依赖倒置原则。
依赖倒置原则：
把原本的高层建筑依赖底层建筑“倒置”过来，变成底层建筑依赖高层建筑。高层建筑决定需要什么，底层去实现这样的需求，但是高层并不用管底层是怎么实现的。这样就不会出现前面的“牵一发动全身”的情况
控制反转：
就是依赖倒置原则的一种代码设计的思路，具体实现的方法就是所谓的依赖注入（Dependency Injection）
依赖注入:
就是把底层类作为参数传入上层类，实现上层类对下层类的“控制”。
控制反转容器：
自动对代码进行初始化，只需要维护一个Configuration,XML或@Autowired，而不用每次使用new关键字初始化,我们在创建实例的时候不需要了解其中的细节，最后将我们创建的实例全部交给控制反转容器管理。
Spring 提供了以下两种不同类型的容器：
| 容器 | 描述 |
|---|---|
| Spring BeanFactory | 它是最简单的容器，给 DI 提供了基本的支持 |
| Spring ApplicationContext | 该容器添加了更多的企业特定的功能 |
ApplicationContext 容器包括 BeanFactory 容器的所有功能，所以通常建议超过 BeanFactory。BeanFactory 仍然可以用于轻量级的应用程序，如移动设备或基于 applet 的应用程序。
Spring Bean
bean 是一个被实例化，组装，并通过 Spring IoC 容器所管理的对象。
2、面向方面的程序设计（AOP）
场景：
比如我们去银行查询余额、取钱、存钱，进行这三个操作业务之前，我们都需要验证身份，验证身份通过之后，才会进行具体的操作，我们需要在每个业务流程增加验证身份的代码。如果验证身份的逻辑发生改变，相关的地方都需要调整，业务复杂程度增加，可维护性降低，针对此问题，我们可以将验证身份定义为横向业务，封装成可复用的模块，利用切面技术使用到需要用到的地方。
定义：
面向对象编程定义纵向业务，AOP是对面向对象的补充，定义横向业务。面向切面把横跨多个业务和多次调用的功能封装成一个可复用的模块，命名为切面，然后将这个这个切面利用面向切面技术运用于需要用到的地方，不用修改原有的业务逻辑，减少侵入性，达到简化业务流程、方法增强和提高开发效率的目的，比如日志记录、声明性事务、安全性，和缓存等等。
通知的类型
Spring 方面可以使用下面提到的五种通知工作：
| 通知 | 描述 |
|---|---|
| 前置通知 | 在一个方法执行之前，执行通知。 |
| 后置通知 | 在一个方法执行之后，不考虑其结果，执行通知。 |
| 返回后通知 | 在一个方法执行之后，只有在方法成功完成时，才能执行通知。 |
| 抛出异常后通知 | 在一个方法执行之后，只有在方法退出抛出异常时，才能执行通知。 |
| 环绕通知 | 在建议方法调用之前和之后，执行通知。 |
实现自定义方面
Spring 支持 @AspectJ annotation style 的方法和基于模式的方法来实现自定义方面。
| 方法 | 描述 |
|---|---|
| XML Schema based | 方面是使用常规类以及基于配置的 XML 来实现的。 |
| @AspectJ based | @AspectJ 引用一种声明方面的风格作为带有 Java 5 注释的常规 Java 类注释。 |