Spring框架之我見（二）——代理模式

聊完了工廠模式，下面咱們來講Spring框架中的另外一個核心設計模式——代理模式（Proxy Pattern）。

代理模式

你們能夠先不用看概念，先舉個吃飯的例子：好比說咱們想吃飯，咱們能夠選擇本身作飯吃、去飯店吃、叫外賣吃。若是咱們選擇本身作着吃，咱們就須要去買菜、作飯、吃飯、吃完飯還要刷碗。其實咱們真正想作的就只有吃飯而已，其餘的都是與業務無關，可是又不得不作的事。可是咱們叫外賣就不同了，外賣小哥會把飯送到咱們手裏，吃完飯咱們也不須要刷碗，直接把包裝扔掉就能夠了，咱們這裏先不討論環保的問題。這裏的外賣小哥就至關因而咱們的代理。代理咱們去飯店，或者買菜的過程。

有了代理咱們就能夠更專一於咱們真正要作的事--吃飯。代理能夠幫咱們把一些髒活累活全都幹了。
在咱們寫代碼過程當中那些是髒活累活呢？

舉個最簡單的例子：在JDBC中，當咱們完成數據庫操做以後，咱們還要關閉一堆Connection、Statement、ResultSet並且每一個都還要判空，還要捕獲異常，要多麻煩有多麻煩。有了代理咱們就能夠把這些都交給代理去作，本身只作最核心的業務邏輯就能夠了。

固然代理模式還有一些其餘的用途：

1. 日誌管理；
2. 事務控制；
3. 權限管理；

那麼有人就會問了：代理模式最終不是仍是得咱們本身實現嗎？既然這樣，咱們直接將這些邏輯直接寫在代碼內部反而更簡單了呢？

這就涉及到兩種代理模式的分類：靜態代理和動態代理。雖然他們的理論都是一致的，可是在實現方式上面卻迥然不一樣。
靜態代理: 每當咱們想代理一個類，咱們就要爲這個類建立一個相應的代理類，讓它在咱們的業務基礎上作一些瑣碎的事，可是這就像上面的朋友的疑問同樣，咱們直接將這些邏輯直接寫在代碼內部反而更簡單。可是這並不表明靜態代理就是一無可取。至少他作到了，業務代碼與其餘代碼的分離。而且靜態代理也是咱們理解動態代理的基礎。
動態代理：經過Java反射的方式爲一批具備相同代理邏輯的類動態的建立代理，這樣能夠大大的提升了咱們的開發的效率。主要分爲JDK代理和CGlib代理。可是它也有缺點，那就是實現太過於複雜。

可是Spring框架卻爲咱們克服了動態代理的缺點，使咱們不須要在考慮動態代理的編寫，而是爲咱們自動生成動態代理，讓咱們開發變得更加如魚得水。下一篇咱們就直奔咱們的主題具體聊聊咱們的Spring框架，看它是如何作到的。

仍是那句話，這裏只是記錄我我的的理解，若是你們須要更加深刻的瞭解能夠參考菜鳥教程.