資訊專欄INFORMATION COLUMN
摘要：表示少女與緊耦合在它的構(gòu)造函數(shù)中自行創(chuàng)建了。面向切面編程往往被定義為促使軟件系統(tǒng)實(shí)現(xiàn)關(guān)注點(diǎn)的分離一項(xiàng)技術(shù)系統(tǒng)由許多不同的組件組成，每個(gè)組件各負(fù)責(zé)一特定的功能。我們可以把切面想象為覆蓋在很多組件之上的一個(gè)外殼。
第1章 Spring之旅 說(shuō)明
1、本文抄寫了《Spring 實(shí)戰(zhàn)》重點(diǎn)內(nèi)容，參考了GitHub上的代碼
2、每個(gè)人的學(xué)習(xí)方式不一樣，但目的是一樣的，活學(xué)活用。最近一直在聽《我們不一樣》
3、本文只為記錄作為以后參考，要想真正領(lǐng)悟Spring的強(qiáng)大，請(qǐng)看原書。
4、代碼和筆記在這里GitHub,對(duì)你有幫助的話，歡迎點(diǎn)贊。
本章內(nèi)容：
Spring的bean容器
介紹Spring的核心模塊
更為強(qiáng)大的Spring生態(tài)系統(tǒng)
Spring的新功能
對(duì)于Java程序員來(lái)說(shuō)，這是一個(gè)很好的時(shí)代..........
Spring是Java歷史中很重要的組成部分。
在誕生之初，創(chuàng)建Spring的主要目的是用來(lái)代替更加重量級(jí)的企業(yè)級(jí)Java技術(shù)，尤其是EJB。相對(duì)于EJB來(lái)說(shuō)，Spring提供了 更加輕量級(jí)和簡(jiǎn)單的編程模型.它增強(qiáng)了簡(jiǎn)單老式的Java對(duì)象(Plain Old Java Object POJO)的功能，使其具備了之前只有EJB和其他企業(yè)級(jí)Java規(guī)范才具有的功能。
盡管J2EE能夠趕上Spring的步伐，但Spring也沒(méi)有停止前進(jìn)(我們程序員也一樣，根本停不下來(lái)...),Spring繼續(xù)在其他領(lǐng)域發(fā)展，移動(dòng)開發(fā)、社交API集成、NoSQL數(shù)據(jù)庫(kù)、云計(jì)算以及大數(shù)據(jù)都是Spring正在涉足和創(chuàng)新的領(lǐng)域。Spring的前景會(huì)更加美好(Java也是，Java9的模塊化，只是我們需要學(xué)習(xí)的還有很多).
對(duì)于Java開發(fā)者來(lái)說(shuō)，這是一個(gè)很好的時(shí)代
1.1簡(jiǎn)化Java開發(fā)Spring是一個(gè)開源框架，最早由Rod Johnson創(chuàng)建，Spring是為了解決企業(yè)級(jí)應(yīng)用開發(fā)的復(fù)雜性而創(chuàng)建的，使用Spring可以讓簡(jiǎn)單的JavaBean實(shí)現(xiàn)之前只有EJB才能完成的事，但Spring不僅僅局限于服務(wù)器端的開發(fā)，任何Java應(yīng)用都能在簡(jiǎn)單性、可測(cè)試性、和松耦合等方面從Spring中受益。
一個(gè)Sping組件可以是任何形式的POJO。所有的理念都可以追溯到Spring最恨本的使命上：簡(jiǎn)化Java開發(fā)。
為了降低Java開發(fā)的復(fù)雜性，Spring采取了以下4種關(guān)鍵策略：
基于POJO的輕量級(jí)和最小入侵性編程；
通過(guò)依賴注入和面向接口實(shí)現(xiàn)松耦合；
基于切面和慣例進(jìn)行聲明式編程：
通過(guò)切面和模板減少樣板代碼；
1.1.1 激發(fā)POJO的潛力很多框架通過(guò)強(qiáng)迫應(yīng)用繼承他們的類或?qū)崿F(xiàn)它們的接口從而導(dǎo)致應(yīng)用于框架綁死。
Spring避免因自身的API而弄亂你的應(yīng)用代碼。Spring不會(huì)強(qiáng)迫你實(shí)現(xiàn)Spring所規(guī)范的接口或繼承Spring所規(guī)范的類，相反，在基于Spring的構(gòu)建的應(yīng)用中，它的類通常沒(méi)有任何跡象表明你使用了Spring。最壞的場(chǎng)景是，一個(gè)類或許會(huì)使用Spring注解，但它依舊是POJO。
package com.guo.spring
public class HelloWordBean {
public String sayHello() {
return "Hello World"
}
}
可以看到，這是一個(gè)簡(jiǎn)單普通的Java類——POJO。沒(méi)有任何地方表明它是一個(gè)Spring組件。Spring的非侵入式編程模型意味著這個(gè)類在Spring應(yīng)用和非Spring應(yīng)用中都可以發(fā)揮同樣的作用。
盡管簡(jiǎn)單，但POJO一樣可以擁有魔力，Spring賦予POJO魔力的方式之一就是通過(guò)DI來(lái)裝配它們。
1.1.2 依賴注入依賴注入現(xiàn)在已經(jīng)演變成一項(xiàng)復(fù)雜的編程技巧或設(shè)計(jì)模式的理念
任何一個(gè)有實(shí)際意義的應(yīng)用都會(huì)由兩個(gè)或更多的類組成，這些類相互之間進(jìn)行協(xié)作來(lái)完成特定的業(yè)務(wù)邏輯。按照傳統(tǒng)的做法，每個(gè)對(duì)象負(fù)責(zé)管理與自己相互協(xié)作的對(duì)象的引用(即它所依賴的對(duì)象)，這就會(huì)導(dǎo)致高度耦合和難以測(cè)試的代碼。
/**
* Created by guo on 20/2/2018.
* damsel表示：少女
*/
public class DamselRescuingKnight implements Knight {
private RescueDamselQuest quest;
public DamselRescuingKnight ( RescueDamselQuest quest) {
//與RescueDamselQuest緊耦合
this.quest = new RescueDamselQuest();
}
@Override
public void embarkOnQuest() {
quest.embark();
}
}
DamselRescueingKnight在它的構(gòu)造函數(shù)中自行創(chuàng)建了RescueDamselQuest。這使得兩者緊緊的耦合在一起。因此極大的限制了騎士執(zhí)行探險(xiǎn)的能力。在這樣一個(gè)測(cè)試中 ，你必須保證當(dāng)騎士embarkOnQuest方法被調(diào)用的時(shí)候，探險(xiǎn)embark方法也要被調(diào)用。但是沒(méi)有一個(gè)簡(jiǎn)單明了的方式能夠測(cè)試。
耦合具有兩面性：
緊密耦合的代碼難以岑氏，難以復(fù)用，難以理解，并且在典型的表現(xiàn)出"打地鼠"式的BUG特性,（修復(fù)一個(gè)bug，將會(huì)出現(xiàn)一個(gè)或更多的bug).
一定的程度耦合又是必須的，完全沒(méi)有耦合的代碼什么都做不了。為了完成更有實(shí)際意義的功能，不同的類必須以適當(dāng)?shù)姆绞竭M(jìn)行交互，總而言之，耦合是必須的，但需要謹(jǐn)慎對(duì)待
通過(guò)DI，對(duì)象的依賴關(guān)系將由系統(tǒng)中負(fù)責(zé)協(xié)調(diào)各對(duì)象的第三方組件在創(chuàng)建對(duì)象的時(shí)候設(shè)定，對(duì)象無(wú)需自行創(chuàng)建或管理他們的依賴關(guān)系，依賴關(guān)系將被自動(dòng)注入到需要它們的對(duì)象中。
依賴注入會(huì)將所依賴的關(guān)系自動(dòng)交給目標(biāo)對(duì)象，而不是讓對(duì)象自己去獲取依賴
BraveKnight足夠靈活可以接受任何賦予他的探險(xiǎn)任務(wù)。
/**
* Created by guo on 20/2/2018.
*/
public class BraveKnight implements Knight {
public Quest quest;
public BraveKnight(Quest quest) { //Quest被注入進(jìn)來(lái)
this.quest = quest;
}
@Override
public void embarkOnQuest() {
quest.embark();
}
}
不同于之前的DamselRescuingKnight，BraveKnight沒(méi)有自行創(chuàng)建探險(xiǎn)任務(wù)，而是在構(gòu)造的時(shí)候把探險(xiǎn)任務(wù)作為構(gòu)造參數(shù)傳入。這是依賴注入的方式之一，即構(gòu)造注入(constructor injection).
需要注意的是，傳入的探險(xiǎn)類型是一個(gè)Quest，也就是所有的探險(xiǎn)任務(wù)都必須實(shí)現(xiàn)的一個(gè)接口。所以BraveKnight能夠響應(yīng)RescueDamselQuest、SlayDragonQuest、MakeRoundTableRounderQuesst 等任意的Quest實(shí)現(xiàn)。
這里的要點(diǎn)是BraveKnight沒(méi)有有特定的Quest實(shí)現(xiàn)發(fā)生耦合。對(duì)他來(lái)說(shuō)，被要求挑戰(zhàn)的探險(xiǎn)任務(wù)只要實(shí)現(xiàn)了Quest接口，那么具體的是那種類型就無(wú)關(guān)緊要了。這就是DI帶來(lái)最大的收益——松耦合。**如果一個(gè)對(duì)象只通過(guò)接口(而不是具體的實(shí)現(xiàn)或初始化過(guò)程)來(lái)表明依賴關(guān)系，那么這種依賴就能夠在對(duì)象本身毫不情況的情況下，用不同的具體實(shí)例進(jìn)行替換。
對(duì)依賴進(jìn)行替換的一個(gè)最常用方法就是在測(cè)試的時(shí)候使用mock實(shí)現(xiàn)。
import static org.mockito.Mockito.*;
public class BraveKnightTest {
@Test
public void knightShouldEmbarkQuest() {
Quest mockQuest = mock(Quest.class); //創(chuàng)建mock Quest
BraveKnight knight = new BraveKnight(mockQuest); //注入mock Quest；
knight.embarkOnQuest();
verify(mockQuest,times(1)).embark();
}
}
可以通過(guò)mock框架Mockito去創(chuàng)建一個(gè)Quest接口的mock實(shí)現(xiàn)。通過(guò)這個(gè)mock對(duì)象，就可以創(chuàng)建一個(gè)新的BraveKnight實(shí)例，并通過(guò)構(gòu)造器注入到這個(gè)mock Quest。當(dāng)調(diào)用embarkOnQUest方法時(shí)，你可以要求Mockito框架驗(yàn)證Quest的mock實(shí)現(xiàn)的embark方法僅僅被調(diào)用了一次。
將Quest注入到Knight中
希望BraveKnight所進(jìn)行的探險(xiǎn)任務(wù)是殺死一只怪龍，
public class SlayDragonQuest implements Quest {
private PrintStream stream;
public SlayDragonQuest(PrintStream stream) {
this.stream = stream;
}
@Override
public void embark() {
stream.println("Embarking on quest to slay the dragon!!,順便還可以學(xué)英語(yǔ)，一舉兩得。");
}
SlayDragonQuest實(shí)現(xiàn)類Quest接口，這樣它就適合注入到BraveKnight中了，與其他入門不同的是，SlayDragonQuest沒(méi)有使用System.out.println();,而是在構(gòu)造方法中請(qǐng)求一個(gè)更為通用的PrintStream。
創(chuàng)建應(yīng)用組件之間協(xié)作的行為成為裝配。Spring有多種裝配Bean的方式，采用XML是一種常用的方式。
knights.xml，該文件將BraveKnight，SlayDragonQuest和PrintStream裝配到一起。
在這里，BraveKnight和SlayDragonQuest被聲明為Spring中的bean。就BraveKnight bean來(lái)講，他在構(gòu)造時(shí)傳入對(duì)SlayDragonQuest bean的引用，將其作為構(gòu)造器參數(shù)。同時(shí)，SlayDragonQuest bean 的聲明使用了Spring表達(dá)式語(yǔ)言(Spring Expression Language)，將System.out(一個(gè)PrintStream)傳入到了SlayDragonQuest的構(gòu)造器中，
在SpEL中, 使用T()運(yùn)算符會(huì)調(diào)用類作用域的方法和常量. 例如, 在SpEL中使用Java的Math類, 我們可以像下面的示例這樣使用T()運(yùn)算符：
T(java.lang.Math)
T()運(yùn)算符的結(jié)果會(huì)返回一個(gè)java.lang.Math類對(duì)象.
Spring提供了基于Java的配置可作為XML的替代方案。
import guo.knights.BraveKnight;
import guo.knights.Knight;
import guo.knights.Quest;
import guo.knights.SlayDragonQuest;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
/**
* Created by guo on 20/2/2018.
*/
@Configuration
public class KnightConfig {
@Bean
public Knight knight() {
return new BraveKnight(quest());
}
@Bean
public Quest quest() {
return new SlayDragonQuest(System.out);
}
}
不管使用的是基于XML的配置還是基于Java的配置，DI所帶來(lái)的收益都是相同的。盡管BraveKnight依賴于Quest，但是它并不知道傳遞給它的是什么類型的Quest，與之類似，SlayDragonQuest依賴于PrintStream，但是編譯時(shí)，并不知道PrintStream長(zhǎng)啥樣子。只有Spring通過(guò)他的配置，能夠了解這些組成部分是如何裝配起來(lái)的。這樣就可以在不改變 所依賴的類的情況下，修改依賴關(guān)系。
**接下來(lái)，我們只需要裝載XML配置文件，并把應(yīng)用啟動(dòng)起來(lái)。
Spring通過(guò)應(yīng)用上下文(Application context) 裝載bean的定義，并把它們組裝起來(lái)。Spring應(yīng)用上下文全權(quán)負(fù)責(zé)對(duì)象的創(chuàng)建個(gè)組裝，Spring自帶了多種應(yīng)用上下文的實(shí)現(xiàn)，他們之間的主要區(qū)別僅僅在于如何加載配置。
因?yàn)閗nights.xml中的bean是使用XML文件進(jìn)行配置的，所以選擇ClassPathXmlApplicationContext作為應(yīng)用上下文相對(duì)是比較合適的。該類加載位于應(yīng)用程序類路徑下的一個(gè)或多個(gè)Xml配置文件。
public class KnightMain {
public static void main(String[] args) {
ClassPathXmlApplicationContext context =
new ClassPathXmlApplicationContext("spring/knights.xml"); //加載Sprinig應(yīng)用上下文
Knight knight = context.getBean(Knight.class); //獲取knight bean
knight.embarkOnQuest(); //使用knight調(diào)用方法
context.close(); //關(guān)閉應(yīng)用上下文
}
}
輸出如下：
Embarking on quest to slay the dragon!!,順便還可以學(xué)英語(yǔ)，一舉兩得。
這里的main()方法基于knight.xml文件創(chuàng)建了spring應(yīng)用上下文。隨后他調(diào)用該應(yīng)用上下文獲取一個(gè)ID為knighht的bean。得到Knighht對(duì)象的引用后，只需要簡(jiǎn)單調(diào)用embarkOnQuest方法就可以執(zhí)行所賦予的探險(xiǎn)任務(wù)了。只有knights.xml知道哪個(gè)騎士執(zhí)行力那種任務(wù)。
1.1.3 應(yīng)用切面DI能夠讓相互協(xié)作的軟件組件保持松耦合，而面向切面編程(aspect-oriented programming AOP) 允許你把遍布應(yīng)用各處的功能分離出來(lái)形成可重用的組件。
面向切面編程往往被定義為促使軟件系統(tǒng)實(shí)現(xiàn)關(guān)注點(diǎn)的分離一項(xiàng)技術(shù),系統(tǒng)由許多不同的組件組成，每個(gè)組件各負(fù)責(zé)一特定的功能。除了實(shí)現(xiàn)自身核心的功能之外，這些組件還經(jīng)常承擔(dān)著額外的職責(zé)。諸如日志、事務(wù)管理、和安全這樣的系統(tǒng)服務(wù)經(jīng)常融入到自身具有核心業(yè)務(wù)邏輯的組件中。這些系統(tǒng)通常被稱為橫切關(guān)注點(diǎn)。，因此他們會(huì)跨越系統(tǒng)多個(gè)組件。
如果將這些關(guān)注點(diǎn)分散到多個(gè)組件中去，你的代碼將會(huì)帶來(lái)雙重的復(fù)雜性。
實(shí)現(xiàn)系統(tǒng)關(guān)注點(diǎn)功能的代碼嫁給你會(huì)重復(fù)出現(xiàn)在多個(gè)組件中。這意味著如果你要改變這些關(guān)注點(diǎn)的邏輯，必須修噶各個(gè)模塊中相關(guān)的實(shí)現(xiàn)。即使你把這些關(guān)注點(diǎn)抽象成一個(gè)獨(dú)立的模塊，其他模塊只是調(diào)用方法。但方法的調(diào)用還是會(huì)重復(fù)出現(xiàn)在各個(gè)模塊中。
組件會(huì)因?yàn)槟切┡c自身核心業(yè)務(wù)無(wú)關(guān)的代碼而變得混亂。一個(gè)向地址薄增加地址條目的方法應(yīng)該只關(guān)注如何添加地址。而不應(yīng)該關(guān)注它是不是安全的，或者是否需要事務(wù)的支持。
AOP能使這些服務(wù)模塊化，并以聲明的方式將它們應(yīng)用到它們要影響的組件中去。所造成的結(jié)果就是這些組件會(huì)具有哥哥你好的內(nèi)聚性并且會(huì)更加關(guān)注自身的業(yè)務(wù)，安全不需要了解涉及系統(tǒng)服務(wù)所帶來(lái)的復(fù)雜性。總之AOP能確保POJO的簡(jiǎn)單性。
我們可以把切面想象為覆蓋在很多組件之上的一個(gè)外殼。應(yīng)用是由哪些實(shí)現(xiàn)各自業(yè)務(wù)功能模塊組成的，借助AOP，可以使用各種功能層去包裹核心業(yè)務(wù)層，,這些層以聲明的方式靈活的應(yīng)用到系統(tǒng)中，你的核心應(yīng)用甚至根本不知道他們的存在。這是一個(gè)非常強(qiáng)大的理念，可以將安全，事務(wù)，日志關(guān)注點(diǎn)與核心業(yè)務(wù)相分離。**
每一個(gè)人都熟知騎士所做的任何事情，這是因?yàn)樵佊卧?shī)人用詩(shī)歌記載了騎士的事跡并將其進(jìn)行傳唱。假設(shè)我們需要使用詠游詩(shī)人這個(gè)服務(wù)類來(lái)記載騎士的所有事跡。
詠游詩(shī)人是中世界的音樂(lè)記錄器
/**
* Created by guo on 20/2/2018.
* 詠游詩(shī)人，作為騎士的一個(gè)切面
*/
public class Minstrel {
private PrintStream stream;
public Minstrel(PrintStream stream) {
this.stream = stream;
}
public void singBeforeQuest() {
stream.println("Fa la la ,the Knight is so brabe"); //探險(xiǎn)之前調(diào)用
}
public void singAfterQuest() {
stream.println("Tee hee hhe,the brave knight " + "did embark on a quest"); //探險(xiǎn)之后調(diào)用
}
}
Minstrel只有兩個(gè)簡(jiǎn)單的方法的類，在騎士執(zhí)行每一個(gè)探險(xiǎn)任務(wù)之前，singBeforeQuest()被調(diào)用；在騎士完成探險(xiǎn)任務(wù)之后，singAfterQuest()方法被調(diào)用。在這兩種情況下，Minstrel都會(huì)通過(guò)一個(gè)PrintStream類來(lái)歌頌騎士的事跡，這個(gè)類通過(guò)構(gòu)造器注入進(jìn)來(lái)。
但利用AOP，你可以聲明詠游詩(shī)人西部歌頌騎士的 探險(xiǎn)事跡，而騎士本身不直接訪問(wèn)Minstrel的方法
要將Minstrel抽象為一個(gè)切面，你所需要做的事情就是在一個(gè)Spring配置文件中聲明它，，
