代理模式
代理模式，也叫委托模式。
Spring AOP 是基于動態代理來實現 AOP 的
定義
- 為
其他對象提供一種代理以控制對這個對象的訪問。 - 它的作用就是
通過提供一個代理類，讓我們在調用目標方法的時候，不再是直接對目標方法進行調用，而是通過代理類間接調用。
在某些情況下，一個對象不適合或者不能直接引用另一個對象，而代理對象可以在客戶端和目標對象之間起到中介的作用。
使用代理前：
使用代理后：
代理模式角色
| 角色名稱 | 描述 | 房屋租賃中的對應角色 |
|---|---|---|
Subject | 業務接口類：可以是抽象類或者接口（不一定有）。 定義了業務操作的接口。 | 房屋租賃的通用操作（如出租房屋） |
RealSubject | 業務實現類：具體的業務執行，也就是 被代理對象。 | 房東 |
Proxy | 代理類：RealSubject 的代理。代理對象內部含有對 RealSubject 的引用，并實現 Subject 接口。 | 中介 |
UML 類圖如下：
簡單總結一下：
- 首先，
Subject是一個接口或者抽象類，定義了RealSubject和Proxy的共同方法。 RealSubject是實際執行任務的對象，而Proxy則控制對 RealSubject 的訪問。
兩種代理模式的區別
代理模式可以在不修改被代理對象的基礎上，通過擴展代理類，進行一些功能的附加與增強。
根據代理的創建時期，代理模式分為靜態代理和動態代理，靜態代理是在編譯時就確定代理關系，而動態代理是在運行時動態生成的。
- 靜態代理：
- 由程序員
創建代理類或特定工具自動生成源代碼再對其編譯； - 在
程序運行前，代理類的.class 文件就已經存在了。
- 由程序員
- 動態代理：
- 在程序運行時，運用
反射機制，動態創建而成。
- 在程序運行時，運用
靜態代理
靜態代理：在程序運行前，代理類的 .class 文件就已經存在了。
在出租房子之前，中介已經做好了相關的工作，就等租戶來租房子了；
我們通過代碼來加深理解。以房租租賃為例：
定義接口（定義房東要做的事情，也是中介需要做的事情）:
實現接口（房東出租房子）：
代理（中介，幫房東出租房子）：
RealSubject是實際執行任務的對象，而Proxy則控制對 RealSubject 的訪問；代理對象內部含有對 RealSubject 的引用，并實現 Subject 接口；
所以中介類中，應該有房東，因為只有房東授權，中介才能帶中介看房子：
中介的 saleHouse() 調用房東的 saleHouse()，表示真正賣房的人是房東：
本質是房東的 saleHouse() 借助中介的 saleHouse() 套了一層殼：
租客來看房了，房租對中介進行授權，讓中介有帶租客看房子的權力：
我們在拆的細一點：
上面的代碼邏輯是，房東需要出租一個房子 target 給租客，房東先把房子 target 這個任務給中介；
但是上面的代碼還是不夠好，因為租房子應該使用接口的方法：
修改：
運行結果：
上面這個代理實現方式就是靜態代理（仿佛啥也沒干）。
從上述程序可以看出，雖然靜態代理也完成了對目標對象的代理，但是由于代碼都寫死了，對目標對象的每個方法的增強都是手動完成的，非常不靈活。所以日常開發幾乎看不到靜態代理的場景。
接下來新增需求：中介又新增了其他業務：代理房屋出售。
我們需要對上述代碼進行修改：
- 接口定義修改。
- 接口實現修改。
- 代理類修改。
從上述代碼可以看出，我們修改接口（Subject）和業務實現類（RealSubject）時，還需要修改代理（Proxy）。
同樣的，如果有新增接口（Subject）和業務實現類（RealSubject），也需要對每一個業務實現類新增代理類（Proxy）。
既然代理的流程是一樣的，有沒有一種辦法，讓他們通過一個代理類來實現呢？ 這就需要用到動態代理技術了。
動態代理
相比于靜態代理來說，動態代理更加靈活。
我們不需要針對每個目標對象都單獨創建一個代理對象，而是把這個創建代理對象的工作推遲到程序運行時由 JVM 來實現。也就是說動態代理在程序運行時，根據需要動態創建生成。
比如房屋中介，我不需要提前預測都有哪些業務，而是業務來了我再根據情況創建。
Java 也對動態代理進行了實現，并給我們提供了一些 API，常見的實現方式有兩種：
- JDK 動態代理。
- CGLIB 動態代理。
動態代理在我們日常開發中使用的相對較少，但是在框架中幾乎是必用的一門技術。
學會了動態代理之后，對于我們理解和學習各種框架的原理也非常有幫助：
https://xiaolllei.blog.csdn.net/article/details/147427226?spm=1011.2415.3001.5331
組件)
，源碼可白嫖!)
