我們到底為什麼要用 IoC 和 AOP

RudeCrab發表於2021-02-03

IoCAOP.png

作為一名 Java 開發,對 Spring 框架是再熟悉不過的了。Spring 支援的控制反轉(Inversion of Control,縮寫為IoC)和面向切面程式設計(Aspect-oriented programming,縮寫為AOP)早已成為我們的開發習慣,彷彿 Java 開發天生就該如此。人總是會忽略習以為常的事物,所有人都熟練使用 IoC 和 AOP,卻鮮有人說得清楚到底為什麼要用 IoC 和 AOP。

技術肯定是為了解決某個問題而誕生,要弄清楚為什麼使用 IoC 和 AOP,就得先弄清楚不用它們會碰到什麼問題。

IoC

我們現在假設回到了沒有 IoC 的時代,用傳統的 Servlet 進行開發。

傳統開發模式的弊端

三層架構是經典的開發模式,我們一般將檢視控制、業務邏輯和資料庫操作分別抽離出來單獨形成一個類,這樣各個職責就非常清晰且易於複用和維護。大致程式碼如下:

@WebServlet("/user")
public class UserServlet extends HttpServlet {
    // 用於執行業務邏輯的物件
    private UserService userService = new UserServiceImpl();
    
    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        // ...省略其他程式碼
            
        // 執行業務邏輯
        userService.doService();
        
        // ...返回頁面檢視
    }
}
public class UserServiceImpl implements UserService{
    // 用於運算元據庫的物件
    private UserDao userDao = new UserDaoImpl();
    
    @Override
    public void doService() {
        // ...省略業務邏輯程式碼
            
        // 執行資料庫操作
        userDao.doUpdate();
        
        // ...省略業務邏輯程式碼
    }
}
public class UserDaoImpl implements UserDao{
    @Override
    public void doUpdate() {
        // ...省略JDBC程式碼
    }
}

上層依賴下層的抽象,程式碼就分為了三層:

2-1.png

業界普遍按這種分層方式組織程式碼,其核心思想是職責分離。層次越低複用程度越高,比如一個 DAO 物件往往會被多個 Service 物件使用,一個 Service 物件往往也會被多個 Controller 物件使用:

2-2.png

條理分明,井然有序。這些被複用的物件就像一個個的元件,供多方使用。

雖然這個倒三角看上去非常漂亮,然而我們目前的程式碼有一個比較大的問題,那就是我們只做到了邏輯複用,並沒有做到資源複用

上層呼叫下一層時,必然會持有下一層的物件引用,即成員變數。目前我們每一個成員變數都會例項化一個物件,如下圖所示:

2-3.png

每一個鏈路都建立了同樣的物件,造成了極大的資源浪費。本應多個 Controller 複用同一個 Service,多個 Service 複用同一個 DAO。現在變成了一個 Controller建立多個重複的 Service,多個 Service 又建立了多個重複的 DAO,從倒三角變成了正三角。

許多元件只需要例項化一個物件就夠了,建立多個沒有任何意義。針對物件重複建立的問題,我們自然而然想到了單例模式。只要編寫類時都將其寫為單例,這樣就避免了資源浪費。但是,引入設計模式必然會帶來複雜性,況且還是每一個類都為單例,每一個類都會有相似的程式碼,其弊端不言自明。

有人可能會說,那我不在意“這點”資源浪費了,我伺服器記憶體大無所謂,我只求開發便捷痛快不想寫額外的程式碼。

確實,三層架構達到邏輯複用已經非常方便了,還奢求其他的幹什麼呢。但就算不管資源問題,目前程式碼還有一個致命缺陷,那就是變化的代價太大

假設有 10 個 Controller 依賴了 UserService,最開始例項化的是 UserServiceImpl,後面需要換一個實現類 OtherUserServiceImpl,我就得逐個修改那 10 個 Controller,非常麻煩。更換實現類的需求可能不會太多,沒多大說服力。那我們們看另一個情況。

之前我們們演示的元件建立過程非常簡單,new 一下就完了,可很多時候建立一個元件沒那麼容易。比如 DAO 物件要依賴一個這樣的資料來源元件:

public class UserDaoImpl implements UserDao{
    private MyDataSource dataSource;

    public UserDaoImpl() {
        // 構造資料來源
        dataSource = new MyDataSource("jdbc:mysql://localhost:3306/test", "root", "password");
        // 進行一些其他配置
        dataSource.setInitiaSize(10);
        dataSource.setMaxActive(100);
        // ...省略更多配置項
    }
}

該資料來源元件要想真正生效需要對其進行許多配置,這個建立和配置過程是非常麻煩的。而且配置可能會隨著業務需求的變化經常更改,這時候你就需要修改每一個依賴該元件的地方,牽一髮而動全身。這還只是演示了一個資料來源的建立配置過程,真實開發中可有太多元件和太多配置需要編碼了,其麻煩程度堪稱恐怖。

當然,這些問題都可以引入設計模式來解決,不過這樣一來又繞回去了:設計模式本身也會帶來複雜性。這就像一種死迴圈:傳統開發模式編碼複雜,要想解決這種複雜卻得陷入另一種複雜。難道沒有辦法解決了嗎?當然不是的,在講優秀解決方案前,我們先來梳理一下目前出現的問題:

  • 建立了許多重複物件,造成大量資源浪費;

  • 更換實現類需要改動多個地方;

  • 建立和配置元件工作繁雜,給元件呼叫方帶來極大不便。

透過現象看本質,這些問題的出現都是同一個原因:元件的呼叫方參與了元件的建立和配置工作

其實呼叫方只需關注元件如何呼叫,至於這個元件如何建立和配置又與呼叫方有什麼關係呢?就好比我去餐館只需點菜,飯菜並不需要我親自去做,餐館自然會做好給我送過來。如果我們編碼時,有一個「東西」能幫助我們建立和配置好那些元件,我們只負責呼叫該多好。這個「東西」就是容器。

容器這一概念我們已接觸過,Tomcat 就是 Servlet 的容器,它幫我們建立並配置好 Servlet,我們只需編寫業務邏輯即可。試想一下,如果 Servlet 要我們自己建立,HttpRequest、HttpResponse 物件也需要我們自己配置,那程式碼量得有多恐怖。

Tomcat 是 Servlet 容器,只負責管理 Servlet。我們平常使用的元件則需要另一種容器來管理,這種容器我們稱之為 IoC 容器

控制反轉和依賴注入

控制反轉,是指物件的建立和配置的控制權從呼叫方轉移給容器。好比在家自己做菜,菜的味道全部由自己控制;去餐館吃飯,菜的味道則是交由餐館控制。IoC 容器就擔任了餐館的角色。

有了 IoC 容器,我們可以將物件交由容器管理,交由容器管理後的物件稱之為 Bean。呼叫方不再負責元件的建立,要使用元件時直接獲取 Bean 即可:

@Component
public class UserServiceImpl implements UserService{
    @Autowired // 獲取 Bean
    private UserDao userDao;
}

呼叫方只需按照約定宣告依賴項,所需要的 Bean 就自動配置完畢了,就好像在呼叫方外部注入了一個依賴項給其使用,所以這種方式稱之為 依賴注入(Dependency Injection,縮寫為 DI)。控制反轉和依賴注入是一體兩面,都是同一種開發模式的表現形式

IoC 輕而易舉地解決了我們剛剛總結的問題:

物件交由容器管理後,預設是單例的,這就解決了資源浪費問題。

若要更換實現類,只需更改 Bean 的宣告配置,即可達到無感知更換:

public class UserServiceImpl implements UserService{
    ...
}

// 將該實現類宣告為 Bean
@Component
public class OtherUserServiceImpl implements UserService{
    ...
}

現在元件的使用和元件的建立與配置完全分離開來。呼叫方只需呼叫元件而無需關心其他工作,這極大提高了我們的開發效率,也讓整個應用充滿了靈活性、擴充套件性。

這樣看來,我們如此中意 IoC 不是沒有道理的。

AOP

我們再來假設沒有 AOP 會怎樣。

物件導向的侷限性

物件導向程式設計(Object-oriented programming,縮寫:OOP)的三大特性:封裝、繼承、多型,我們早已用得爐火純青。OOP 的好處已無需贅言,相信大家都有體會。這裡我們們來看一下 OOP 的侷限性。

當有重複程式碼出現時,可以就將其封裝出來然後複用。我們通過分層、分包、分類來規劃不同的邏輯和職責,就像之前講解的三層架構。但這裡的複用的都是核心業務邏輯,並不能複用一些輔助邏輯,比如:日誌記錄、效能統計、安全校驗、事務管理,等等。這些邊緣邏輯往往貫穿你整個核心業務,傳統 OOP 很難將其封裝:

public class UserServiceImpl implements UserService {
    @Override
    public void doService() {
        System.out.println("---安全校驗---");
        System.out.println("---效能統計 Start---");
        System.out.println("---日誌列印 Start---");
        System.out.println("---事務管理 Start---");

        System.out.println("業務邏輯");

        System.out.println("---事務管理 End---");
        System.out.println("---日誌列印 End---");
        System.out.println("---效能統計 End---");
    }
}

為了方便演示,這裡只用了列印語句,就算如此這程式碼看著也很難受,而且這些邏輯是所有業務方法都要加上,想想都恐怖。

OOP 是至上而下的程式設計方式,猶如一個樹狀圖,A呼叫B、B呼叫C,或者A繼承B、B繼承C。這種方式對於業務邏輯來說是合適的,通過呼叫或繼承以複用。而輔助邏輯就像一把閘刀橫向貫穿所有方法,如圖2-4所示:

2-4.png

這一條條橫線彷彿切開了 OOP 的樹狀結構,猶如一個大蛋糕被切開多層,每一層都會執行相同的輔助邏輯,所以大家將這些輔助邏輯稱為層面或者切面。

代理模式用來增加或增強原有功能再適合不過了,但切面邏輯的難點不是不修改原有業務,而是對所有業務生效。對一個業務類增強就得新建一個代理類,對所有業務增強,每個類都要新建代理類,這無疑是一場災難。而且這裡只是演示了一個日誌列印的切面邏輯,如果我再加一個效能統計切面,就得新建一個切面代理類來代理日誌列印的代理類,一旦切面多起來這個代理類巢狀就會非常深。

面向切面程式設計(Aspect-oriented programming,縮寫為 AOP)正是為了解決這一問題而誕生的技術。

面向切面程式設計

AOP 不是 OOP 的對立面,它是對 OOP 的一種補充。OOP 是縱向的,AOP 是橫向的,兩者相結合方能構建出良好的程式結構。AOP 技術,讓我們能夠不修改原有程式碼,便能讓切面邏輯在所有業務邏輯中生效

我們只需宣告一個切面,寫上切面邏輯:

@Aspect // 宣告一個切面
@Component
public class MyAspect {
    // 原業務方法執行前
    @Before("execution(public void com.rudecrab.test.service.*.doService())")
    public void methodBefore() {
        System.out.println("===AspectJ 方法執行前===");
    }

    // 原業務方法執行後
    @AfterReturning("execution(* com.rudecrab.test.service..doService(..))")
    public void methodAddAfterReturning() {
        System.out.println("===AspectJ 方法執行後===");
    }
}

無論你有一個業務方法,還是一萬個業務方法,對我們開發者來說只需編寫一次切面邏輯,就能讓所有業務方法生效,極大提高了我們的開發效率。

總結

IoC 解決了以下問題:

  • 建立了許多重複物件,造成大量資源浪費;

  • 更換實現類需要改動多個地方;

  • 建立和配置元件工作繁雜,給元件呼叫方帶來極大不便。

AOP 解決了以下問題:

  • 切面邏輯編寫繁瑣,有多少個業務方法就需要編寫多少次。

本文到這裡就結束了,我是「RudeCrab」,一隻粗魯的螃蟹,我們下篇文章再見。

關注「RudeCrab」微信公眾號,和螃蟹一起橫行霸道。

相關文章