Java開發(fā)到底為什么要用 IoC 和 AOP
作為一名 Java 開發(fā),對(duì) Spring 框架是再熟悉不過的了。Spring 支持的控制反轉(zhuǎn)(Inversion of Control,縮寫為IoC)和面向切面編程(Aspect-oriented programming,縮寫為AOP)早已成為我們的開發(fā)習(xí)慣,仿佛 Java 開發(fā)天生就該如此。人總是會(huì)忽略習(xí)以為常的事物,所有人都熟練使用 IoC 和 AOP,卻鮮有人說得清楚到底為什么要用 IoC 和 AOP。
技術(shù)肯定是為了解決某個(gè)問題而誕生,要弄清楚為什么使用 IoC 和 AOP,就得先弄清楚不用它們會(huì)碰到什么問題。
一、IoC
我們現(xiàn)在假設(shè)回到了沒有 IoC 的時(shí)代,用傳統(tǒng)的 Servlet 進(jìn)行開發(fā)。
1. 傳統(tǒng)開發(fā)模式的弊端
三層架構(gòu)是經(jīng)典的開發(fā)模式,我們一般將視圖控制、業(yè)務(wù)邏輯和數(shù)據(jù)庫操作分別抽離出來單獨(dú)形成一個(gè)類,這樣各個(gè)職責(zé)就非常清晰且易于復(fù)用和維護(hù)。大致代碼如下:
@WebServlet("/user")
public class UserServlet extends HttpServlet {
// 用于執(zhí)行業(yè)務(wù)邏輯的對(duì)象
private UserService userService = new UserServiceImpl();
@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
// ...省略其他代碼
// 執(zhí)行業(yè)務(wù)邏輯
userService.doService();
// ...返回頁面視圖
}
}
public class UserServiceImpl implements UserService{
// 用于操作數(shù)據(jù)庫的對(duì)象
private UserDao userDao = new UserDaoImpl();
@Override
public void doService() {
// ...省略業(yè)務(wù)邏輯代碼
// 執(zhí)行數(shù)據(jù)庫操作
userDao.doUpdate();
// ...省略業(yè)務(wù)邏輯代碼
}
}
public class UserDaoImpl implements UserDao{
@Override
public void doUpdate() {
// ...省略JDBC代碼
}
}
上層依賴下層的抽象,代碼就分為了三層:

業(yè)界普遍按這種分層方式組織代碼,其核心思想是職責(zé)分離。層次越低復(fù)用程度越高,比如一個(gè) DAO 對(duì)象往往會(huì)被多個(gè) Service 對(duì)象使用,一個(gè) Service 對(duì)象往往也會(huì)被多個(gè) Controller 對(duì)象使用:

條理分明,井然有序。這些被復(fù)用的對(duì)象就像一個(gè)個(gè)的組件,供多方使用。
雖然這個(gè)倒三角看上去非常漂亮,然而我們目前的代碼有一個(gè)比較大的問題,那就是我們只做到了邏輯復(fù)用,并沒有做到資源復(fù)用。
上層調(diào)用下一層時(shí),必然會(huì)持有下一層的對(duì)象引用,即成員變量。目前我們每一個(gè)成員變量都會(huì)實(shí)例化一個(gè)對(duì)象,如下圖所示:

每一個(gè)鏈路都創(chuàng)建了同樣的對(duì)象,造成了極大的資源浪費(fèi)。本應(yīng)多個(gè) Controller 復(fù)用同一個(gè) Service,多個(gè) Service 復(fù)用同一個(gè) DAO。現(xiàn)在變成了一個(gè) Controller創(chuàng)建多個(gè)重復(fù)的 Service,多個(gè) Service 又創(chuàng)建了多個(gè)重復(fù)的 DAO,從倒三角變成了正三角。
許多組件只需要實(shí)例化一個(gè)對(duì)象就夠了,創(chuàng)建多個(gè)沒有任何意義。針對(duì)對(duì)象重復(fù)創(chuàng)建的問題,我們自然而然想到了單例模式。只要編寫類時(shí)都將其寫為單例,這樣就避免了資源浪費(fèi)。但是,引入設(shè)計(jì)模式必然會(huì)帶來復(fù)雜性,況且還是每一個(gè)類都為單例,每一個(gè)類都會(huì)有相似的代碼,其弊端不言自明。
有人可能會(huì)說,那我不在意“這點(diǎn)”資源浪費(fèi)了,我服務(wù)器內(nèi)存大無所謂,我只求開發(fā)便捷痛快不想寫額外的代碼。
確實(shí),三層架構(gòu)達(dá)到邏輯復(fù)用已經(jīng)非常方便了,還奢求其他的干什么呢。但就算不管資源問題,目前代碼還有一個(gè)致命缺陷,那就是變化的代價(jià)太大。
假設(shè)有 10 個(gè) Controller 依賴了 UserService,最開始實(shí)例化的是 UserServiceImpl,后面需要換一個(gè)實(shí)現(xiàn)類 OtherUserServiceImpl,我就得逐個(gè)修改那 10 個(gè) Controller,非常麻煩。更換實(shí)現(xiàn)類的需求可能不會(huì)太多,沒多大說服力。那咱們看另一個(gè)情況。
之前咱們演示的組件創(chuàng)建過程非常簡(jiǎn)單,new 一下就完了,可很多時(shí)候創(chuàng)建一個(gè)組件沒那么容易。比如 DAO 對(duì)象要依賴一個(gè)這樣的數(shù)據(jù)源組件:
public class UserDaoImpl implements UserDao{
private MyDataSource dataSource;
public UserDaoImpl() {
// 構(gòu)造數(shù)據(jù)源
dataSource = new MyDataSource("jdbc:mysql://localhost:3306/test", "root", "password");
// 進(jìn)行一些其他配置
dataSource.setInitiaSize(10);
dataSource.setMaxActive(100);
// ...省略更多配置項(xiàng)
}
}
該數(shù)據(jù)源組件要想真正生效需要對(duì)其進(jìn)行許多配置,這個(gè)創(chuàng)建和配置過程是非常麻煩的。而且配置可能會(huì)隨著業(yè)務(wù)需求的變化經(jīng)常更改,這時(shí)候你就需要修改每一個(gè)依賴該組件的地方,牽一發(fā)而動(dòng)全身。這還只是演示了一個(gè)數(shù)據(jù)源的創(chuàng)建配置過程,真實(shí)開發(fā)中可有太多組件和太多配置需要編碼了,其麻煩程度堪稱恐怖。
當(dāng)然,這些問題都可以引入設(shè)計(jì)模式來解決,不過這樣一來又繞回去了:設(shè)計(jì)模式本身也會(huì)帶來復(fù)雜性。這就像一種死循環(huán):傳統(tǒng)開發(fā)模式編碼復(fù)雜,要想解決這種復(fù)雜卻得陷入另一種復(fù)雜。難道沒有辦法解決了嗎?當(dāng)然不是的,在講優(yōu)秀解決方案前,我們先來梳理一下目前出現(xiàn)的問題:
- 創(chuàng)建了許多重復(fù)對(duì)象,造成大量資源浪費(fèi);
- 更換實(shí)現(xiàn)類需要改動(dòng)多個(gè)地方;
- 創(chuàng)建和配置組件工作繁雜,給組件調(diào)用方帶來極大不便。
透過現(xiàn)象看本質(zhì),這些問題的出現(xiàn)都是同一個(gè)原因:組件的調(diào)用方參與了組件的創(chuàng)建和配置工作。
其實(shí)調(diào)用方只需關(guān)注組件如何調(diào)用,至于這個(gè)組件如何創(chuàng)建和配置又與調(diào)用方有什么關(guān)系呢?就好比我去餐館只需點(diǎn)菜,飯菜并不需要我親自去做,餐館自然會(huì)做好給我送過來。如果我們編碼時(shí),有一個(gè)「東西」能幫助我們創(chuàng)建和配置好那些組件,我們只負(fù)責(zé)調(diào)用該多好。這個(gè)「東西」就是容器。
容器這一概念我們已接觸過,Tomcat 就是 Servlet 的容器,它幫我們創(chuàng)建并配置好 Servlet,我們只需編寫業(yè)務(wù)邏輯即可。試想一下,如果 Servlet 要我們自己創(chuàng)建,HttpRequest、HttpResponse 對(duì)象也需要我們自己配置,那代碼量得有多恐怖。
Tomcat 是 Servlet 容器,只負(fù)責(zé)管理 Servlet。我們平常使用的組件則需要另一種容器來管理,這種容器我們稱之為 IoC 容器。
2. 控制反轉(zhuǎn)和依賴注入
控制反轉(zhuǎn),是指對(duì)象的創(chuàng)建和配置的控制權(quán)從調(diào)用方轉(zhuǎn)移給容器。好比在家自己做菜,菜的味道全部由自己控制;去餐館吃飯,菜的味道則是交由餐館控制。IoC 容器就擔(dān)任了餐館的角色。
有了 IoC 容器,我們可以將對(duì)象交由容器管理,交由容器管理后的對(duì)象稱之為 Bean。調(diào)用方不再負(fù)責(zé)組件的創(chuàng)建,要使用組件時(shí)直接獲取 Bean 即可:
@Component
public class UserServiceImpl implements UserService{
@Autowired // 獲取 Bean
private UserDao userDao;
}
調(diào)用方只需按照約定聲明依賴項(xiàng),所需要的 Bean 就自動(dòng)配置完畢了,就好像在調(diào)用方外部注入了一個(gè)依賴項(xiàng)給其使用,所以這種方式稱之為 依賴注入(Dependency Injection,縮寫為 DI)。控制反轉(zhuǎn)和依賴注入是一體兩面,都是同一種開發(fā)模式的表現(xiàn)形式。
IoC 輕而易舉地解決了我們剛剛總結(jié)的問題:
對(duì)象交由容器管理后,默認(rèn)是單例的,這就解決了資源浪費(fèi)問題。
若要更換實(shí)現(xiàn)類,只需更改 Bean 的聲明配置,即可達(dá)到無感知更換:
public class UserServiceImpl implements UserService{
...
}
// 將該實(shí)現(xiàn)類聲明為 Bean
@Component
public class OtherUserServiceImpl implements UserService{
...
}
現(xiàn)在組件的使用和組件的創(chuàng)建與配置完全分離開來。調(diào)用方只需調(diào)用組件而無需關(guān)心其他工作,這極大提高了我們的開發(fā)效率,也讓整個(gè)應(yīng)用充滿了靈活性、擴(kuò)展性。
這樣看來,我們?nèi)绱酥幸?IoC 不是沒有道理的。
二、AOP
我們?cè)賮砑僭O(shè)沒有 AOP 會(huì)怎樣。
1. 面向?qū)ο蟮木窒扌?/h3>
面向?qū)ο缶幊蹋∣bject-oriented programming,縮寫:OOP)的三大特性:封裝、繼承、多態(tài),我們?cè)缫延玫脿t火純青。OOP 的好處已無需贅言,相信大家都有體會(huì)。這里咱們來看一下 OOP 的局限性。
當(dāng)有重復(fù)代碼出現(xiàn)時(shí),可以就將其封裝出來然后復(fù)用。我們通過分層、分包、分類來規(guī)劃不同的邏輯和職責(zé),就像之前講解的三層架構(gòu)。但這里的復(fù)用的都是核心業(yè)務(wù)邏輯,并不能復(fù)用一些輔助邏輯,比如:日志記錄、性能統(tǒng)計(jì)、安全校驗(yàn)、事務(wù)管理,等等。這些邊緣邏輯往往貫穿你整個(gè)核心業(yè)務(wù),傳統(tǒng) OOP 很難將其封裝:
public class UserServiceImpl implements UserService {
@Override
public void doService() {
System.out.println("---安全校驗(yàn)---");
System.out.println("---性能統(tǒng)計(jì) Start---");
System.out.println("---日志打印 Start---");
System.out.println("---事務(wù)管理 Start---");
System.out.println("業(yè)務(wù)邏輯");
System.out.println("---事務(wù)管理 End---");
System.out.println("---日志打印 End---");
System.out.println("---性能統(tǒng)計(jì) End---");
}
}
為了方便演示,這里只用了打印語句,就算如此這代碼看著也很難受,而且這些邏輯是所有業(yè)務(wù)方法都要加上,想想都恐怖。
OOP 是至上而下的編程方式,猶如一個(gè)樹狀圖,A調(diào)用B、B調(diào)用C,或者A繼承B、B繼承C。這種方式對(duì)于業(yè)務(wù)邏輯來說是合適的,通過調(diào)用或繼承以復(fù)用。而輔助邏輯就像一把閘刀橫向貫穿所有方法,
如圖

這一條條橫線仿佛切開了 OOP 的樹狀結(jié)構(gòu),猶如一個(gè)大蛋糕被切開多層,每一層都會(huì)執(zhí)行相同的輔助邏輯,所以大家將這些輔助邏輯稱為層面或者切面。
代理模式用來增加或增強(qiáng)原有功能再適合不過了,但切面邏輯的難點(diǎn)不是不修改原有業(yè)務(wù),而是對(duì)所有業(yè)務(wù)生效。對(duì)一個(gè)業(yè)務(wù)類增強(qiáng)就得新建一個(gè)代理類,對(duì)所有業(yè)務(wù)增強(qiáng),每個(gè)類都要新建代理類,這無疑是一場(chǎng)災(zāi)難。而且這里只是演示了一個(gè)日志打印的切面邏輯,如果我再加一個(gè)性能統(tǒng)計(jì)切面,就得新建一個(gè)切面代理類來代理日志打印的代理類,一旦切面多起來這個(gè)代理類嵌套就會(huì)非常深。
面向切面編程(Aspect-oriented programming,縮寫為 AOP)正是為了解決這一問題而誕生的技術(shù)。
2. 面向切面編程
AOP 不是 OOP 的對(duì)立面,它是對(duì) OOP 的一種補(bǔ)充。OOP 是縱向的,AOP 是橫向的,兩者相結(jié)合方能構(gòu)建出良好的程序結(jié)構(gòu)。AOP 技術(shù),讓我們能夠不修改原有代碼,便能讓切面邏輯在所有業(yè)務(wù)邏輯中生效。
我們只需聲明一個(gè)切面,寫上切面邏輯:
@Aspect // 聲明一個(gè)切面
@Component
public class MyAspect {
// 原業(yè)務(wù)方法執(zhí)行前
@Before("execution(public void com.rudecrab.test.service.*.doService())")
public void methodBefore() {
System.out.println("===AspectJ 方法執(zhí)行前===");
}
// 原業(yè)務(wù)方法執(zhí)行后
@AfterReturning("execution(* com.rudecrab.test.service..doService(..))")
public void methodAddAfterReturning() {
System.out.println("===AspectJ 方法執(zhí)行后===");
}
}
無論你有一個(gè)業(yè)務(wù)方法,還是一萬個(gè)業(yè)務(wù)方法,對(duì)我們開發(fā)者來說只需編寫一次切面邏輯,就能讓所有業(yè)務(wù)方法生效,極大提高了我們的開發(fā)效率。
三、總結(jié)
IoC 解決了以下問題:
- 創(chuàng)建了許多重復(fù)對(duì)象,造成大量資源浪費(fèi);
- 更換實(shí)現(xiàn)類需要改動(dòng)多個(gè)地方;
- 創(chuàng)建和配置組件工作繁雜,給組件調(diào)用方帶來極大不便。
AOP 解決了以下問題:
切面邏輯編寫繁瑣,有多少個(gè)業(yè)務(wù)方法就需要編寫多少次。
以上就是Java開發(fā)到底為什么要用 IoC 和 AOP的詳細(xì)內(nèi)容,更多關(guān)于Java IoC和AOP的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
springmvc與mybatis集成配置實(shí)例詳解
這篇文章主要介紹了springmvc與mybatis集成配置實(shí)例詳解的相關(guān)資料,非常不錯(cuò),具有參考借鑒價(jià)值,需要的朋友可以參考下2016-09-09
關(guān)于HashMap 并發(fā)時(shí)會(huì)引起死循環(huán)的問題解析
JDK1.8之前采用頭插,即在鏈表結(jié)構(gòu)上每次都把數(shù)據(jù)放在鏈表頭部。JDK1.8采用尾插方法,很多朋友在學(xué)習(xí)Java并發(fā)容器和框架時(shí),看到為什么要使用ConcurrentHashMap時(shí)不知道究其原因,今天小編通過本文給大家介紹下HashMap 并發(fā)死循環(huán)問題,一起看看吧2021-05-05
idea編輯XML文件出現(xiàn):Tag name expected報(bào)錯(cuò)的解決
在XML中,一些特殊字符不能直接使用,因?yàn)樗鼈儽槐A粲糜赬ML文檔的結(jié)構(gòu)和語法,如果直接使用這些保留字符,會(huì)導(dǎo)致解析錯(cuò)誤,正確的做法是使用實(shí)體引用或字符引用,或者使用CDATA標(biāo)記將這些字符包裹起來2025-01-01
Java使用Redis實(shí)現(xiàn)微博熱搜功能
在社交平臺(tái)上,熱搜功能是一個(gè)非常重要的組成部分,它展示了當(dāng)前最熱門的話題,幫助用戶迅速了解最受關(guān)注的事件,Redis 是一個(gè)高性能的鍵值存儲(chǔ)系統(tǒng),通常用于緩存和實(shí)時(shí)數(shù)據(jù)存儲(chǔ),本文將通過 Java 結(jié)合 Redis 實(shí)現(xiàn)一個(gè)簡(jiǎn)化版的微博熱搜功能,需要的朋友可以參考下2024-12-12
springboot使用注解實(shí)現(xiàn)鑒權(quán)功能
這篇文章主要介紹了springboot使用注解實(shí)現(xiàn)鑒權(quán)功能,本文通過實(shí)例代碼給大家介紹的非常詳細(xì),感興趣的朋友跟隨小編一起看看吧2024-12-12
SpringBoot進(jìn)行數(shù)據(jù)加密和解密的詳細(xì)指南
對(duì)稱加密算法使用相同的密鑰進(jìn)行加密和解密,其主要優(yōu)點(diǎn)包括速度快和實(shí)現(xiàn)簡(jiǎn)單,常見的對(duì)稱加密算法有 AES、DES 等,本文將以 AES 為例,展示如何在 Spring Boot 項(xiàng)目中進(jìn)行數(shù)據(jù)加密和解密,需要的朋友可以參考下2024-11-11

