spring源碼的設計模式

轉:https://blog.csdn.net/huyang0304/article/details/82928900

接下來咱們只介紹在Spring中經常使用的設計模式。

1.一、簡單工廠模式（Factory）

應用場景：又叫作靜態工廠方法（StaticFactoryMethod）模式，但不屬於23種設計模式之一。簡單工廠模式的實質是由一個工廠類根據傳入的參數，動態決定應該建立哪個產品類。

Spring中的BeanFactory就是簡單工廠模式的體現，根據傳入一個惟一的標識來得到Bean對象，可是否是在傳入參數後建立仍是傳入參數前建立這個要根據具體狀況來定。

歸類

特色

窮舉

建立型模式

是複雜工廠模式的思惟模型

批量生產、標準化

1.二、工廠方法模式（FactoryMethod）

應用場景：一般由應用程序直接使用new建立新的對象，爲了將對象的建立和使用相分離，採用工廠模式,即應用程序將對象的建立及初始化職責交給工廠對象。

通常狀況下,應用程序有本身的工廠對象來建立Bean.若是將應用程序本身的工廠對象交給Spring管理,那麼Spring

管理的就不是普通的Bean,而是工廠Bean。

歸類

特色

窮舉

建立型模式

對於調用者來講，隱藏了複雜的邏輯處理過程，調用者只關心執行結果。

對於工廠來講要對結果負責，保證生產出符合規範的產品。

流水線生產

1.三、單例模式（Singleton）

應用場景：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。

Spring中的單例模式完成了後半句話，即提供了全局的訪問點BeanFactory。但沒有從構造器級別去控制單例，這是由於Spring管理的是是任意的Java對象。Spring下默認的Bean均爲單例。

歸類

特色

窮舉

建立型模式

保證從系統啓動到系統終止，全過程只會產生一個實例。

當咱們在應用中遇到功能性衝突的時候，須要使用單例模式。

配置文件、日曆、OC容器

 

經常使用單例模式寫法：餓漢式、懶漢式、註冊式、序列化。

1.四、原型模式（Prototype）

應用場景：原型模式就是從一個對象再建立另一個可定製的對象，並且不須要知道任何建立的細節。

所謂原型模式，就是Java中的克隆技術，以某個對象爲原型。複製出新的對象。顯然新的對象具有原型對象的特色，效率高（避免了從新執行構造過程步驟）。

歸類

特色

窮舉

建立型模式

首先有一個原型。

數據內容相同，但對象實例不一樣（徹底兩個個體）。

孫悟空吹毫毛

1.五、代理模式（Proxy）

應用場景：爲其餘對象提供一種代理以控制對這個對象的訪問。從結構上來看和Decorator模式相似，但Proxy是控制，更像是一種對功能的限制，而Decorator是增長職責。

Spring的Proxy模式在AOP中有體現，好比JdkDynamicAopProxy和Cglib2AopProxy。

歸類

特色

窮舉

結構型模式

執行者、被代理人

對於被代理人來講，這件事情是必定要作的，可是我本身又不想作或者沒有時間作。

對於代理人而言，須要獲取到被代理的人我的資料，只是參與整個過程的某個或幾個環節。

租房中介、售票黃牛、婚介、經紀人、快遞、事務代理、非侵入式日誌監聽

1.六、策略模式（Strategy）

應用場景：定義一系列的算法，把它們一個個封裝起來，而且使它們可相互替換。本模式使得算法可獨

立於使用它的客戶而變化。

Spring中在實例化對象的時候用到Strategy模式，在SimpleInstantiationStrategy有使用。

歸類

特色

窮舉

行爲型模式

最終執行結果是固定的。

執行過程和執行邏輯不同。

旅遊出行方式

1.七、模板方法模式（TemplateMethod）

定義一個操做中的算法的骨架，而將一些步驟延遲到子類中。TemplateMethod使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。

TemplateMethod模式通常是須要繼承的。這裏想要探討另外一種對TemplateMethod的理解。Spring中的JdbcTemplate，在用這個類時並不想去繼承這個類，由於這個類的方法太多，可是咱們仍是想用到JdbcTemplate

已有的穩定的、公用的數據庫鏈接，那麼咱們怎麼辦呢？咱們能夠把變化的東西抽出來做爲一個參數傳入JdbcTemplate的方法中。可是變化的東西是一段代碼，並且這段代碼會用到JdbcTemplate中的變量。怎麼辦？那咱們就用回調對象吧。在這個回調對象中定義一個操縱JdbcTemplate中變量的方法，咱們去實現這個方法，就把變化的東西集中到這裏了。而後咱們再傳入這個回調對象到JdbcTemplate，從而完成了調用。這就是TemplateMethod不須要繼承的另外一種實現方式。

歸類

特色

窮舉

行爲型模式

執行流程固定，但中間有些步驟有細微差異（運行時才肯定）。

可實現批量生產。

SpringORM數據模型

1.八、委派模式（Delegate）

應用場景：不屬於23種設計模式之一，是面向對象設計模式中經常使用的一種模式。這種模式的原理爲類B和類A是兩個互相沒有任何關係的類，B具備和A如出一轍的方法和屬性；而且調用B中的方法，屬性就是調用A中同名的方法和屬性。B好像就是一個受A受權委託的中介。第三方的代碼不須要知道A的存在，也不須要和A發生直接的聯繫，經過B就能夠直接使用A的功能，這樣既可以使用到A的各類功能，又可以很好的將A保護起來了，一箭雙鵰。

歸類

特色

窮舉

行爲型模式

要和代理模式區分開來。

持有被委託人的引用。

不關心過程，只關心結果。

經理派發工做任務、Dispatcher

1.九、適配器模式（Adapter）

SpringAOP模塊對BeforeAdvice、AfterAdvice、ThrowsAdvice三種通知類型的支持其實是藉助適配器模式來實現的，這樣的好處是使得框架容許用戶向框架中加入本身想要支持的任何一種通知類型，上述三種通知類型是SpringAOP模塊定義的，它們是AOP聯盟定義的Advice的子類型。

歸類

特色

窮舉

結構型模式

注重兼容、轉換。

適配者與被適配這之間沒有層級關係，也沒有必然聯繫。

知足has-a的關係。

編碼解碼、一拖三充電頭、HDMI轉VGA、Type-C轉USB

1.十、裝飾器模式（Decorator）

應用場景：在咱們的項目中遇到這樣一個問題：咱們的項目須要鏈接多個數據庫，並且不一樣的客戶在每

次訪問中根據須要會去訪問不一樣的數據庫。咱們以往在Spring和Hibernate框架中老是配置一個數據源，於是SessionFactory的DataSource屬性老是指向這個數據源而且恆定不變，全部DAO在使用SessionFactory的時候都是經過這個數據源訪問數據庫。可是如今，因爲項目的須要，咱們的DAO在訪問SessionFactory的時候都不得不在多個數據源中不斷切換，問題就出現了：如何讓SessionFactory在執行數據持久化的時候，根據客戶的需求可以動態切換不一樣的數據源？咱們能不能在Spring的框架下經過少許修改獲得解決？是否有什麼設計模式能夠利用呢？

首先想到在Spring的ApplicationContext中配置全部的DataSource。這些DataSource多是各類不一樣類型的，好比不一樣的數據庫：Oracle、SQLServer、MySQL等，也多是不一樣的數據源：好比Apache提供的org.apache.commons.dbcp.BasicDataSource、Spring提供的org.springframework.jndi.JndiObjectFactoryBean等。而後SessionFactory根據客戶的每次請求，將DataSource屬性設置成不一樣的數據源，以到達切換數據源的目的。

Spring中用到的包裝器模式在類名上有兩種表現：一種是類名中含有Wrapper，另外一種是類名中含有Decorator。基本上都是動態地給一個對象添加一些額外的職責。

歸類

特色

窮舉

結構型模式

一、注重覆蓋、擴展。

二、裝飾器和被裝飾器都實現同一個接口，主要目的是爲了擴展以後依舊保留OOP關係（同宗同源）。

三、知足is-a的關係。

IO流包裝、數據源包裝、簡歷包裝

1.十一、觀察者模式（Observer）

應用場景：定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象

都獲得通知並被自動更新。

Spring中Observer模式經常使用的地方是Listener的實現。如ApplicationListener。————————————————版權聲明：本文爲CSDN博主「yyyyyhu」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/huyang0304/article/details/82928900