咱們爲何要用 IoC 和 AOP

做爲一名 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代碼
    }
}
複製代碼

上層依賴下層的抽象，代碼就分爲了三層：

業界廣泛按這種分層方式組織代碼，其核心思想是職責分離。層次越低複用程度越高，好比一個 DAO 對象每每會被多個 Service 對象使用，一個 Service 對象每每也會被多個 Controller 對象使用：

條理分明，井井有理。這些被複用的對象就像一個個的組件，供多方使用。

雖然這個倒三角看上去很是漂亮，然而咱們目前的代碼有一個比較大的問題，那就是咱們只作到了邏輯複用，並無作到資源複用。

上層調用下一層時，必然會持有下一層的對象引用，即成員變量。目前咱們每個成員變量都會實例化一個對象，以下圖所示：

每個鏈路都建立了一樣的對象，形成了極大的資源浪費。本應多個 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所示：

這一條條橫線彷彿切開了 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」微信公衆號，和螃蟹一塊兒橫行霸道。