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类来增加代码的复杂性。