Java的11種設計模式學習

一：設計模式是最重要的課程之一，堪稱軟件界的九陽真經,設計模式是一大套被反覆使用，多數人知曉的，通過分類編目的，代碼總結，使用設計模式是爲了可重用代碼.讓代碼更容易被他人理解，保證代碼可靠性。
二：學習設計模式最多見的理由是由於咱們能夠借其：

1. 複用解決方案----避免重蹈前人的覆轍，從學習他人的經驗中獲益，用不着爲那些老是會重複出現的問題再次設計解決方案.
2. 肯定通用術語-----設計模式在項目的分析和設計階段提供了共同的基準點.

三：設計模式中通常都遵循這們的原則：

1. 按接口編程.
2. 儘可能使用組合代替繼承.
3. 找出變化並封裝。

下面是具體的設計模式：
l 工廠模式<Factoty>
定義：用一個方法代替構造器和new關鍵字，把對象的建立隱藏起來.
解決的問題：用來解決一個一個生成方式過多，容易產生變更，或者是父類和了類之間容易替換的地方。工廠模式就至關於建立實例對象的new，工廠模式使得咱們沒必要關心具體類是怎麼實現的，它提供了程序的拓展性，下降了耦合度.
l 單例模式<Singleton>
定義：一個類在java虛擬機中只能建立一個對象。
單例模式的構建有兩種方式:
a:懶漢式:指全局的單例實例在第一次被使用時建立。
b:餓漢式:指全局的單例實例在類加載的時候建立。
單例模式必需要知足如下四個條件:

1. 單例類必需要有一個私有的構造器.
2. 單例類的實例必須爲全局的，且用private static修飾.
3. 必須提供一個對外開放的建立對象的方法。
4. 對放的方法必須是用公共，靜態且同步的方法.public synchronized static xxx();

用到的地方：當一個類的實例，有且只能建立一個時用到。
l 門面模式<Facade>
定義：定義一個高層接口，把全部子類的交互，經過這個接口來實現，這個接口集成了全部子系統的類。
<書面說法：爲子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用>
解決問題：子接口繁多，調用複雜，內部交互地方比較多。
l 策略模式<Strategy>
定義：定義一系列的算法，將它們封裝起來，使得它們能夠替換，使用策略模式使得算法可獨立於使用它的客戶而變化。
解決問題：某個具體的解決方法有不少種可選實現。
適用情形：
a:若是在一個系統裏面有許多類，它們之間的區別在於它們的行爲，那麼使用策略模式能夠動態的讓一個對象在許多行爲中選擇一個種行爲。
b:一個系統須要動態地在幾種算法中選擇一種，那麼這些算法能夠包裝到一個個具體算法類裏面，而這些算法都是一個抽象算法類的子類，換言之，這些具本算法類均有統一的接口，因爲多態性原則，客戶端能夠選擇使用任何一個具體類算法，並只持有一個數據類型是抽象算法類的對象.
l 模板模式<Template>
定義：在操做中定義一系列骨架，將一些操做的步驟延遲到子類中。父類定義流程，子類具體實現。
解決問題：主要是解決子類之間代碼或流程的重複問題。
優勢：
1：利用了繼承的方法，在基類中定義了算法的框架，並將算法的可變部他聲明爲可重寫的，由具體子類使用，這樣能夠利用一樣的框架，完成不一樣的功能，它的效率比策略模式高，而且比較簡單。
2：使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。
模板模式的結構：
1>:AbstractClass類，定義了一到多的抽象方法，以供具體子類來實現它們，並且還要實現這一個模板方法，來定義一個算法骨架，該模板方法不只調用前面的抽象方法，也能夠調用其餘的操做，只要能完成自身的使命。
2>：ConcreteClass(具體類)：實現父類中的抽象方法以完成算法中與特定子類相關的步驟。
適用狀況：
1>：一次性實現一個算法的不變的部分，並將可變的行爲留給子類實現。
2>：各子類中的公共行爲應被提取出來集中到一個公共父類中，以免代碼重複，其實這能夠說是一種好的編碼習慣。
3>：控制子類擴展，模板方法只在特定點調用操做，這樣就只容許這些點進行擴展。
若是你不肯子類修改你的模板方法定義的框架，你能夠採用兩種方式來作：
1>：將API中不體現出你的模板方法。
2>：將你的模板方法置爲final就能夠了。
l 適配器模式<Adapter>(將不兼容的變得兼容)
生活中的實例：變壓器。
定義：將一個類的接口轉換成客戶但願的另外一個接口，這樣使得兩個本來不兼容的接口能夠在一塊兒正常工做。
例子:DBUtil的QueryRun類的Update方法,若是提供的是兩個參數,想將它轉換成三個參數,這時候就用到了適配器模式,適配器模式用兩種,一是類適配器,二是對象適配器，但考慮到設計模式中遵循的條件:
a:按接口編程;
b:儘可能使用組合代替繼承.
c:找出變化將它們封裝.
因此這個時候咱們用對象適配器.
解決的問題：已經存在相似功能的類或接口，但方法簽名不同。
l 觀察者模式<Observer>（１：依賴；２：一對多）
定義：定義對一個對象間的一種一對多的關係，當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並自動更新。
<提供給關聯對象一種同步通訊的手段，使某個對象與依賴於它的其它對象保持狀態同步>.
解決問題：解決多個對象間相互依賴關係的相互通知。
意圖：1：當對一個對象的改變須要同時改變其它對象，而不知道具體有多少對象有待改變。
２：當一個對象必須通知其它對象，而它又不能假定其它對是誰，換言之，你不但願這些對象是緊密耦合的。
優缺點：
１：對象之間能夠進行同步通訊
２：能夠同時通知一到多個關聯對象
３：對象之間的關係以鬆耦合的形式，互下依賴。
l 抽象工廠模式<AbstractFactory>實例：衣服，褲子，鞋子它們能夠是阿迪的，耐克的。。。。等等。
定義：提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類。　
使用的緣由：是因爲它能將實現類和它們的生成過程徹底分割開來。
用途 :

• 一個系統要獨立於它的產品的建立、組合和表示時。
• 一個系統要由多個產品系列中的一個來配置時。
• 當你要強調一系列相關的產品對象的設計以便進行聯合使用時。

*　當你提供一個產品類庫，而只想顯示它們的接口而不是實現。
抽象工廠負責管理子工廠對象，子工廠對象生成某一類具體的產品對象。
l 狀態模式<State>(狀態決定行爲)　
狀態模式:生活中的實例:紅,綠,燈.
一:定義: 不一樣的狀態,不一樣的行爲;或者說,每一個狀態有着相應的行爲.
用通俗的話說:就是一個狀態一個行爲,不一樣的狀態有着不一樣的行爲.
二:什麼時候使用:
State模式在實際使用中比較多,適合"狀態的切換".
由於咱們常常會使用If elseif else 進行狀態切換, 若是針對狀態的這樣判斷切換反覆出現,咱們就要聯想到是否能夠採起State模式了.
三:解決的問題:邏輯不是很複雜的,不能解決．它不能解決未知的狀態．
解決問題 　
1) 一個對象的行爲取決於它的狀態, 而且它必須在運行時刻根據狀態改變它的行爲。
2) 一個操做中含有龐大的多分支的條件語句，且這些分支依賴於該對象的狀態。
四:缺點
每一個狀態對應一個具體的狀態類，使得總體分散，邏輯不太清晰
五:優勢
狀態模式的引入免除了代碼中複雜而庸長的邏輯判斷語句。
並且具體狀態角色將具體狀態和它對應的行爲封裝了起來，這使得增長一種新的狀態變得簡單一些．
l 裝飾器模式<Decorator>:生活中的實例:給牆刷油漆.
定義：動態地給一個對象添加一些額外的職責。就增長功能來講，
Decorator模式相比生成子類更爲靈活。
通俗的說:在不改變一個類的源代碼,不經過繼承,實現,就能動態的添加一些額外的功能.
解決問題：一個對象須要常常動態增長屬性或指責
適用性：

• 在不影響其餘對象的狀況下，以動態、透明的方式給單個對象添加職責。
• 處理那些能夠撤消的職責。
• 當不能採用生成子類的方法進行擴充時。一種狀況是，可能有大量獨立的擴展，爲支持每一種組合將產生大量的子類，使得子類數目呈爆炸性增加。

另外一種狀況多是由於類定義被隱藏，或類定義不能用於生成子類。
爲何使用Decorator?
咱們一般可使用繼承來實現功能的拓展,若是這些須要拓展的功能的種類很繁多, 那麼勢必生成不少子類,增長系統的複雜性,同時,使用繼承實現功能拓展,咱們必須可預見這些拓展功能,這些功能是編譯時就肯定了,是靜態的.
使用Decorator的理由是:這些功能須要由用戶動態決定加入的方式和時機.Decorator提供了"即插即用"的方法,在運行期間決定什麼時候增長何種功能.
如何使用?
舉Adapter中的打樁示例,在Adapter中有兩種類:方形樁 圓形樁,Adapter模式展現如何綜合使用這兩個類, 在Decorator模式中,咱們是要在打樁時增長一些額外功能,好比,挖坑 在樁上釘木板等, 不關心如何使用兩個不相關的類.
優勢：
1）提供比繼承更多的靈活性
2）使用不一樣的裝飾組合能夠創造出不一樣行爲的組合
3）須要的類的數目減小
缺點：
1）靈活性帶來比較大的出錯性
2）產生更多的對象，給查錯帶來困難
l 組合模式<Composite>例：connection裏有set,map再下就是ArrayListHashMap
例子：合作各類各樣的樹形菜單。
定義:將對象以樹形結構組織起來,以達成「部分－總體」 的層次結構，
使得客戶端對單個對象和組合對象的使用具備一致性.
解決問題:樹形數據結構的方案．
適用性:

• 你想表示對象的部分-總體層次結構。
• 你但願用戶忽略組合對象與單個對象的不一樣，用戶將統一地使用組合結構中的全部對象。

Composite模式優缺點及適用狀況：
1） 優勢：使客戶端調用簡單，客戶端能夠一致的使用組合結構或其中單個對象，用戶就沒必要關係本身處理的是單個對象仍是整個組合結構,就簡化了客戶端代碼。
2）缺點:我以爲Leaf類徹底不該該來實現Component，應爲它基本只是使用一個顯示的做用，不能進行其餘的操做如添加、刪除等，若是實現Component容易產生誤操做。
/**