Spring---AOP与DI的初步理解

依赖注入
　　依赖注入并没有我们听上去那么复杂，在项目中应用依赖注入，会使代码变的异常简单，更易于理解和测试。
　　任何一个有实际意义的应用，都是多个类组成，这些类之间相互协作，来实现特定的业务逻辑，通常，每个对象负责管理与自己相互协作的对象，这就使得代码具有的侵入性，耦合程度较高，不利于维护。
例如：

上面代码中构造函数自行创建了RescueDamselQuest对象，是的DamselRescuingKinght与RescueDamselQuest类紧密的耦合在了一起，不利于代码的维护和扩展。
　　耦合具有两面性，一方面，紧密的耦合是的代码难以测试和复用，难以理解，并经常会出现修复一个bug会出现一个新的甚至更多的bug，另一方面，一定程度的耦合又是必须的，完全没有耦合的代码什么也做不了。耦合是必须的，但应当小心谨慎的使用。
　　另一种方式，通过依赖注入（DI）,对象的依赖关系将由负责协调对象的第三方组件在创建时设定。对象无需自行创建或管理他们的依赖关系———依赖关系会自动注入到他们所需要的对象中去。
例如：

不同于之前自行创建对象，而是在构造时把任务Quest接口作为参数传入。这是依赖注入的方式之一，即构造器注入。这里的要点是BraveKnights没有与特定的Quest实现发生耦合。对他来说，只要是实现了Quest接口的类，都可以作为参数传入，这就是依赖注入最大的好处——松耦合。
装配：创建应用组件之间的协作行为通常称为装配，Spring提供了多种装配方式。采用XML配置通常是最常见的装配方式。
例如：

其中注入的Quest代码为：

加载包含Knight的Spring上下文：
Spring通过应用上下文ApplicationContext装载Bean的定义，并把他们组装起来。Spring应用上下文全权负责对象的创建和组装。Spring自带了几种应用上下文的实现，他们之间的区别主要是如何加载他们的配置。
knights.xml中的bean实在XML文件中进项声明的，我们可以选ClassPathXmlApplicationContext作为应用上下文。

运行结果：

这里main方法创建了一个Spring应用上下文，该应用下载了knights.xml文件。随后它调用该应用上下文，获取一个ID为knight的对象引用后，调用其embarkOnQuest()方法。

注意：1.knights类完全不知道注入的是哪一种Quest,只有knights.xml文件知道，这就实现了松耦合。

           2.应用上下文：可以理解为程序的运行环境

AOP(应用切面)
依赖注入能让相互协作的软件保持松耦合，而AOP编程允许你把遍布应用各处的的功能分离出来，形成可以重用的组件。
系统由许多不同的组件构成，每一个组件负责特定的功能。除了实现自身的核心功能之外，这些组件还常常承担着额外的职责，例如日志，事务管理和安全等此类的系统服务经常融入到核心逻。这些系统服务通常被称为横切关注点，因为他们总是跨越多个组件，若果这些关注点分散到多个组件中，代码将会引入双重复杂性。
AOP使这些服务组件模块化，并以声明的方式将他们应用到他们需要影响的组件中去，使这些组件具有更高的内聚以及更加关注自身业务，完全不需要了解可能涉及的系统服务的复杂性。总之,AOP确保pojo的绝对简单。
例如：
1.首先我们创建一个Minstrel类，来记录Knight类中embark()方法的执行，如图：

2.将Minstrel类应用到代码中：

运行结果：

这样可以达到预期的效果，但也会导致一些问题，记录knights的行为是Minstrel类自身的工作，不应当牵扯到Knignts类，因为Knight类需要知道哪个类在记录的行为，必须将该类注入进去，回事BraveKnights的代码复杂化（例如 如果不需要记录自身行为，或者minstrel为空怎么办？），
为了解决这个问题，我们可以利用AOP把Minstrel抽象为一个切面，只需在配置文件中声明一下，即可完成所需要的操作。
例如：
1.删除调BraveKnights中有关于Minstrel的代码

2.在knights.xml文件中配置通知和切面

3.运行结果：

通过少量的XML配置，你就可以把Minstrel声明为一个Spring切面，而不需要在Brave类中注入Minstrel类来增加代码的复杂性。