一句話解釋設計模式

時間 2019-11-19

標籤一句話解釋設計模式简体版

原文原文鏈接

學習設計模式的第一感覺就是,我原來好好的代碼(或者說是很簡單的代碼),非得套用這麼複雜的寫法去實現,簡直是脫了褲子放屁html

相信不少人應該有和我同樣的想法,在這裏首先咱們要明確,這麼複雜的設計模式必定是有用的,在你未成爲大牛以前,必定要相信大牛必定是對的.那他的做用是什麼呢?首先要了解面向對象的六大原則java

咱們javaer核心編程思想就是面向對象,也就是你的代碼要面向對象,能new對象能夠說已經面向對象入門了,可是代碼依然不夠面向對象,不夠爽,一套能讓人爽的代碼,要基於如下幾個原則算法

第一原則:千萬不要XB優化你的代碼,慢慢等待時機,一兩句代碼就解決的事,千萬不要涉及設計模式,不要管什麼模式,永遠記住,過早的優化是萬惡之源(由於一切事物有利就有弊,面向對象帶來的問題就是對象過於'豐富',理解起來須要更多的時間),如下的規則適用於大系統,大功能,毫不適用於小功能,寫個hello world就別設計模式了,這就是爲啥學設計模式感受不爽,由於例子中的代碼太簡單了,根本不須要用到設計模式,可是例子又不能太複雜,不然本末倒置了,只能本身在工做中慢慢領悟了,當你感受代碼愈來愈冗餘了,修改愈來愈麻煩了,這個時候才該考慮是否應該優化重構了編程

面向對象六大原則

參考: http://www.javashuo.com/article/p-gzyowwwq-ee.html設計模式

一、單一職責原則(SRP：Single responsibility principle)

　　一個類只負責一種職責，只有這種職責的改變會致使這個類的變動。繞口一點的正統說法：不要存在多於一個緣由致使類變動. 假如：類T 負責有兩種職責 P1，P2；當P1發生改變時，須要修改類T，這時候可能會對P2形成影響。安全

　　軟件工程中的概念 : 判斷設計好壞的標準是高內聚低耦合,啥是TM的高內聚,這就是TM的高內聚,高內聚就是說一段代碼只負責一個功能,第二個功能讓別的代碼去負責,不要跟我說這說那,老子TM就只會BB,別的啥也不幹,這就是高內聚數據結構

　　往小點說,每一個方法都應該是內聚的,一個方法只幹一件事情框架

　　因此不要爲了圖代碼量少，二將不一樣職責放入到一個類裏面。能夠寫兩段代碼,再用另外一段將這兩段組合起來,我只負責A功能,你只負責B功能,他只負責整合咱們,沒其餘卵用.工具

二、里氏替換原則(Liskov Substitution Principle LSP)

　　替換麼,啥是替換,我能換成你,就是替換性能

　　好比:

　　　　A a = new A(); //聲明A對象

　　　　B b = new B(); //聲明B對象

　　　　a = b ; //將A對象替換成B對象

　　這叫替換.

　　這叫雞兒的替換,連編譯都通不過(小聲BB).

　　因此怎麼才能換呢,只有同類才能換,把我換成我?

　　　　A a1 = new A(); //聲明A對象

　　　　A a2 = new A(); //聲明B對象

　　　　a1 = a2 ; //將A對象替換成A對象

　　這到是編譯經過了,但我本身的類型和我本身的類型不能叫替換啊!

　　怎麼玩呢,就只能有父類才行,這裏父類能夠是接口,或者類或者抽象類

　　好比咱們最長見的 List list = new ArrayList(); 能夠替換爲 list = new LinkedList();

　　ArrayList和LinkedList是兩個不一樣的類,但由於都實現了List大接口,因此對於List這個層面來說,他們是一類,能夠替換.

　　因此LSP創建在繼承/實現的基礎上,必須有父子類關係

　　里氏替換原則: 只要父類出現的地方，均可以用子類替換，而且不會對程序形成影響.

　如何保證里氏替換原則呢?須要踐行下面的規範

　　1988年，B. Meyer提出了Design by Contract（契約式設計）理論。DbC從形式化方法中借鑑了一套確保對象行爲和自身狀態的方法，其基本概念很簡單：

　　Pre-condition:

　　每一個方法調用以前，該方法應該校驗傳入參數的正確性，只有正確才能執行該方法，不然認爲調用方違反契約，不予執行。這稱爲前置條件(Pre-condition)。

　　Post-Condition:

　　一旦經過前置條件的校驗，方法必須執行，而且必須確保執行結果符合契約，這稱之爲後置條件(Post-condition)。

　　Invariant:

　　對象自己有一套對自身狀態進行校驗的檢查條件，以確保該對象的本質不發生改變，這稱之爲不變式(Invariant)。

　　以上是單個對象的約束條件。爲了知足LSP，當存在繼承關係時，子類中方法的前置條件必須與超類中被覆蓋的方法的前置條件相同或者更寬鬆；而子類中方法的後置條件必須與超類中被覆蓋的方法的後置條件相同或者更爲嚴格

　　一些OO語言中(好比java)的特性可以說明這一問題：

　　繼承而且覆蓋超類方法的時候，子類中的方法的可見性必須等於或者大於超類中的方法的可見性，子類中的方法所拋出的受檢異常只能是超類中對應方法所拋出的受檢異常的子類。

　　我的認爲里氏替換原則能夠去看下equals方法,equals是Object類的方法,可是Integer和String等類都重寫了父類方法,順序也是先判斷類型是否相同,相同才繼續執行比較,不一樣就直接false,若是我這個例子舉得不合適,望告知

三、依賴倒置原則(Dependence Inversion Principle (DIP))

　　百度百科例子很好直接拿來用: https://baike.baidu.com/item/%E4%BE%9D%E8%B5%96%E5%80%92%E7%BD%AE%E5%8E%9F%E5%88%99/6189149?fr=aladdin

　　簡單講就是面向接口編程:接口通常是行爲的集合，也就是儘量的對行爲抽象。抽象不該該依賴細節，細節應該依賴抽象。

　　面對抽象編程,而不是面對具體編程,也就是代碼不要上來就寫(具體的類/方法),而應該先分析(指定規則/接口方法),有哪些共性啊,若是代碼要擴展怎麼辦?需求變更怎麼辦?

四、接口隔離原則(Interface Segregation Principle (ISP))

　　相似單一職責原則,區別是單一職責講的是代碼功能層面的.這個說的是每一個接口中的功能儘量單一.要把一個大接口分紅多個,而後經過多實現去組合他們,而不是放在一塊兒.

　　接口本質上是兩個類之間關係的紐帶，關係中不須要有的，在接口中不該該體現。

　　如：

　　　　一個A接口中有以下兩個方法: 爆粗口(), 文明用語()

　　　　而後有個Person類來實現這個A接口,而這個Person是個文明人,人家不須要爆粗口() 這個方法,可是沒辦法,你是子類必須實現,並且若是我把接口中的爆粗口() 加了參數,或者改了返回值 ,或者改了名字,這個Person都得跟着改,可是人家不用啊,這就形成了不合理

　　　　怎麼才能合理呢?

　　　　應該開兩個接口 A 只有爆粗口(), B 只有文明用語(),若是一我的是文明人,只須要單一實現B就行了,若是一我的是個正常人常常講文明,但偶爾爆粗口,能夠多實現A,B兩個接口,也能夠專門有一我的接口C繼承A,B兩個接口(爲了整合),讓這個正常人實現C接口便可

五、迪米特法則（Least Knowledge Principle (LKP)）

　　軟件工程中的概念 : 判斷設計好壞的標準是高內聚低耦合,啥是TM的低耦合,這就是低耦合.

　　耦合能夠理解爲鐘錶中緊挨的兩個齒輪,一個轉動必然帶動了另外一個轉動.正如咱們的類,A類和B類,若是A類修改了,使得B沒法正常使用了,也必須跟着修改,那就說明這兩個類耦合性高,反之,就是低耦合.

　　而迪米特法則講的就是一個對象要對其餘對象保持儘量少的瞭解，即低耦合性，低耦合能夠最大限度的保證代碼的可複用性。這個其實是針對被依賴的類來講的，對於被依賴的類，儘量的將複雜的邏輯封裝起來，對外只提供public方法，外部不須要知道內部的邏輯。

　　一開始我理解這個規則的時候,以爲很難以想象,一個類若是和另外一個類低耦合了(不要緊了),那就是兩個單獨的類,但凡他們要有點關係就必須耦合在一塊兒,這是個悖論啊,怎麼才能達到這樣的效果呢?

　　由於不少人只說了上面前半句,沒說後半句,後半句是這樣的 : 迪米特法則不但願類之間創建直接的聯繫。若是真的有須要創建聯繫，也但願能經過它的友元類來轉達。

　　就是說A,B兩個齒輪,這樣是高耦合,想要解耦,咱們引入C齒輪,AB跟C聯繫,AB之間不能聯繫,只能經過中介類C發生關係,這樣,咱們稱AB兩個類低耦合,可是其實AC和BC就高耦合了,這樣也無所謂,由於C只負責聯通(符合單一職責),AB各自負責其功能.

　　應用迪米特法則有可能形成的一個後果就是：系統中存在大量的中介類，這些類之因此存在徹底是爲了傳遞類之間的相互調用關係——這在必定程度上增長了系統的複雜度。

　　有興趣能夠研究一下設計模式的門面模式（Facade）和中介模式（Mediator），都是迪米特法則應用的例子

　　-- 摘自百度百科 https://baike.baidu.com/item/%E8%BF%AA%E7%B1%B3%E7%89%B9%E6%B3%95%E5%88%99/2107000?fr=aladdin

六、開閉原則(Open-Close Principle（OCP）)

　　功能應該對擴展開放,對修改關閉。就是想改是不行的,可是你能夠經過擴展來達到增長功能,或者修改功能的目的.

　　擴展 extends ,明白這個怎麼玩了吧?

　　其實就是我這提供的東西你能用就用,不能用本身繼承下來重寫個人方法,可是別想着改個人源代碼,不然測試就須要好大功夫

　　舉個例子,咱們都用Sring框架,咱們也看源碼,也反編譯,有多少人在本身生產環境中改過源代碼?不都是繼承人家的類,重寫人家的方法,用到的時候new本身的對象麼

GOF23種設計模式

　　整體來講設計模式分爲三大類：

　　建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

　　建立型模式就是造對象,有的好好的new不用,非xjb造.

　　結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

　　結構型模式就是組裝組織多個對象,原本一兩句代碼能解決的問題,非neng一坨類而後互相調用

　　行爲型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代器模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

　　換個角度看問題,將原本一坨順序執行(頂死加點循環判斷)的像屎同樣的代碼(但我能用啊),重構到多個類中,以一種更加精幹的方式展示在世人面前(可是可能可讀性不太好,畢竟代碼分的太散了,或者說由於角度不一樣,須要更大力的去思考去理解)

　　可是隻有這樣,咱們才能更好的面向對象,更好的應對需求的修改啊(你看,Spring的功能不知足你的要求,你本身擴展就行,不須要打電話給人家的RD,讓人家半夜起來改代碼)

理解設計模式:朋友說了這麼一句話:設計模式是一種思想,不要侷限於具體的例子(好比有時候你會以爲某個例子既象某個模式,又想另外一個模式),有時候例子會誤導你的理解,要去看概念,設計模式是爲了解決一些特定場景的問題,答案就在概念中,概念會告訴你這個模式解決了什麼問題,爲何提出這個模式,瞭解了這點,就把握住了理解設計模式的根本.

理解設計模式:面向對象的思想是用來將類關係垂直的構造出來,便於聯繫,而設計模式是將類關係橫向聯繫,方便擴展

建立型模式

　　單例模式:

　　　　這個就不說了,單例省內存,惟一須要注意的就是內部儘可能不要使用全局變量,由於線程不安全

　　建造者模式:

百度百科:建造者模式是設計模式的一種，將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示(就是建立實例的build能夠擴展[傳入不一樣的build建立不一樣的實例])

　　　　原本能本身new對象,設置數據的,爲啥要再來個建造者呢?簡單對象確實不用,可是有一些複雜對象可能構造起來比較麻煩,就像咱們小時候幫別人拼玩具汽車同樣,假如最後的客戶須要的是一輛拼好的汽車,他不須要本身去拼,只須要給你所須要的零件就行,你呢,就是那個建造者,幫別人把零件拼起來,做爲客戶他不須要知道你怎麼拼的,過程如何複雜,只須要你說你要車輪,我提供車輪就行,簡化客戶的操做.

　　　　對於建造者模式,有接口規定每一種零件提供的方法,咱們只須要將這個零件類實現好,提供給建造者(diractor),建造者就能給咱們返回最後的成品,下降客戶端對於最終產品的耦合性

　　原型模式(克隆模式):

　　　　百度百科:用原型實例指定建立對象的種類，而且經過拷貝這些原型建立新的對象。

　　　　根據已有對象建立新對象,使用的是Object類的clone方法,這個方法是protected修飾,可是全部對象都繼承自Object,因此本身能夠重寫這個方法,這個方法調用時會檢查你的類型是否符合Cloneable,這是一個標記接口,因此讓本身的類再實現這個接口,就能夠調用clone方法了.

　　　　這裏分有淺複製和深複製只說,

　　　　深複製:指的是類中所持有的全部對象是否被複制,若是全部對象都複製了一份就是深複製,也就是舊對象中數據變更不會影響新對象內容

　　　　淺複製:指的是類中引用對象並未被複制,只是新對象持有了引用對象的指針,兩個對象持有的是同一個引用,這樣舊對象內數據變更,就會影響新對象

　　　　實現深複製,每層的引用對象都重寫clone方法,而後在重寫的clone方法中顯式調用並給新對象賦值便可

　　工廠方法模式:

　　　　百度百科:工廠方法模式是一種經常使用的類建立型設計模式,此模式的核心精神是封裝類中變化的部分，提取其中個性化善變的部分爲獨立類，經過依賴注入以達到解耦、複用和方便後期維護拓展的目的。它的核心結構有四個角色，分別是抽象工廠；具體工廠；抽象產品；具體產品

　　　　首先簡單工廠模式不算在GOF23種設計模式中,工廠方法其實就是工廠接口生產產品接口,各自下面又有本身的實現,就是工廠實現生產產品實現

　　　　這樣作的好處就是:有接口,那就可擴展,有不一樣的實現,就能夠隨意替換,符合開閉和里氏替換原則

　　抽象工廠模式:

　　　　百度百科:抽象工廠模式是全部形態的工廠模式中最爲抽象和最具通常性的一種形態。抽象工廠模式是指當有多個抽象角色時，使用的一種工廠模式。抽象工廠模式能夠向客戶端提供一個接口，使客戶端在沒必要指定產品的具體的狀況下，建立多個產品族中的產品對象。根據里氏替換原則，任何接受父類型的地方，都應當可以接受子類型。所以，實際上系統所須要的，僅僅是類型與這些抽象產品角色相同的一些實例，而不是這些抽象產品的實例。換言之，也就是這些抽象產品的具體子類的實例。工廠類負責建立抽象產品的具體子類的實例。

　　　　https://blog.csdn.net/u014727260/article/details/82560912

　　　　這個裏面講的很是清楚,感謝博主

　　　　上面的工廠方法一個工廠只生產一類產品,這裏咱們把產品換個名字,叫零件,也就是工廠生產的這個東西不能做爲產品使用

　　　　這裏的產品概念是多個零件組成的一個產品,因此咱們須要多個上面的工廠,負責生產不一樣的零件

　　　　零件有了,就得組裝成產品,咱們這裏產品根據不一樣的零件組成不一樣的產品,

　　　　而組裝多個零件也能夠抽象成一個工廠,因而出現了橫縱兩種座標,一種用來生產零件,一種用來組合零件爲產品

　　　　理解起來可能很是麻煩,可是若是工做中用到其實不至於太難理解

結構型模式

　　適配器模式:

　　　　百度百科:配器模式（有時候也稱包裝樣式或者包裝）將一個類的接口適配成用戶所期待的。一個適配容許一般由於接口不兼容而不能在一塊兒工做的類工做在一塊兒，作法是將類本身的接口包裹在一個已存在的類中。

　　　　適配器就像現實生活中的兩插口轉成三插口那個工具同樣,這個適配器能夠講根本沒增長什麼新功能,就是一個調用別人方法的中介方法而已.

　　　　當你的方法須要調用a()(通常來講,這個a名字是由於接口規定好了),可是a()這個功能和另外一個類的b()如出一轍,那麼咱們能夠再寫一個類,這個類的實現統一接口,而後在內部a(),調用b(),這樣就實現了調用a(),實際執行b()功能,這個新類就是適配器

　　　　其實正常狀況下咱們本身在a()中調用b(),爲啥多創造一個新類呢?就是爲了解耦

　　裝飾器模式:

　　　　菜鳥教程:裝飾器模式（Decorator Pattern）容許向一個現有的對象添加新的功能，同時又不改變其結構。這種類型的設計模式屬於結構型模式，它是做爲現有的類的一個包裝。這種模式建立了一個裝飾類，用來包裝原有的類，並在保持類方法簽名完整性的前提下，提供了額外的功能。

　　　　一共須要三個類: 一個接口,一個原始類,一個裝飾器類

　　　　接口:聲明方法

　　　　原始類:實現接口,重寫方法

　　　　裝飾器類:實現接口,同時在類內部聲明一個接口對象,給外界提供一個傳入原始對象的入口(能夠是set,也能夠是構造器,通常是構造器),在重寫方法時調用原始對象的方法

　　　　因爲裝飾器類也實現了接口,因此能夠裝飾器套裝飾器,最內部是原始對象就行

　　　　符合開閉原則,目的是爲了擴展功能

　　代理模式:

　　　　百度百科:所謂的代理者是指一個類別能夠做爲其它東西的接口。

　　　　一共須要三個類: 一個接口,一個原始類(被代理對象),一個代理對象

　　　　接口:聲明方法

　　　　被代理類:實現接口,重寫方法

　　　　代理類:實現接口,在類內部持有被代理對象,重寫方法時調用被代理對象方法

　　　　爲何要抽出一個代理對象呢,就是說這個被代理類其實徹底能夠實現所有完整的方法,可是呢,方法中有些代碼是通用的,咱們但願把這些重複的代碼重構一下,因此將這些代碼提到代理類中,因此間接的講,被代理對象的功能實際上是不完整的,因此通常客戶端不會直接使用被代理類,而是經過代理類去操做.　　　　

　　裝飾器模式和代理模式區別:

　　　　這兩種模式寫法特別象,只不過一個外殼叫裝飾器,一個外殼叫代理對象,既然叫法不一樣,就說明他們理解角度不一樣,代理類中是抽出共同方法,裝飾器是增長功能(沒有代理類功能不完整,沒有裝飾器功能完整,有了代理類功能正常,有了裝飾器,錦上添花)

　　　　裝飾器模式在於增長功能,可是整個過程當中客戶端是知道有原始對象這個東西的,外殼和原始對象的組合方式是使用傳參的方式組合在一塊兒的,因此原始對象是客戶端new出來的,客戶端即便不使用裝飾器,直接使用原始對象,功能都是完整的

　　　　代理模式在於補充正常功能,但整個過程當中客戶端根本沒有跟原始對象(被代理對象)產生關係,或者說根本不知道有被代理對象,被代理對象應該是直接new在代理對象中的,客戶端只建立代理對象,使用代理對象便可.(可是現實使用過程當中,咱們可能爲了通用,因此沒有將代碼寫死,直接在代理對象中new對象,也是經過傳參的方式傳入的被代理對象,同時這兩種寫法均可以是增長功能的做用[人爲操做],因此咱們會以爲這兩個模式特別像),客戶端通常的不直接使用被代理對象,由於被代理對象功能不全

　　　　這兩種寫法都符合開閉原則,不對原始對象內容修改,想要增長功能在外面套殼子就行

　　外觀模式(門面模式):

　　　　菜鳥教程:外觀模式（Facade Pattern）隱藏系統的複雜性，並向客戶端提供了一個客戶端能夠訪問系統的接口。這種類型的設計模式屬於結構型模式，它向現有的系統添加一個接口，來隱藏系統的複雜性。

　　　　slf4j就是典型的外觀模式

　　　　外觀模式跟上面兩種模式最大的特色就是本身沒有任何功能,只是爲了整合資源,爲客戶端提供統一的調用方式(就好像天貓淘寶同樣,咱們稱其爲平臺,他不生產產品,也不負責售賣,只是提供了一個交易平臺,簡化統一賣家和買家的操做),並且內部持有的對象必定是門戶對象本身建立出來的(本身new),對客戶端保持透明

　　　　目的是爲了解耦,簡化操做,方便隨意替換內部實現

　　　　slf4j就是這樣,咱們寫法是同樣的,具體使用哪一個日誌實現,實際上是slf4j在啓動的時候回去掃描整個類目錄,查找實現類(log4j)提供的一個入口配置,這個入口配置是約定好的,slf4j聲明,log4j實現的,slf4j掃描到就會知道該建立誰了,而且將其初始化,這個過程客戶端並不須要知道,只要按着slf4j寫法寫就行,引用不一樣的日誌實現jar,就能夠實現日誌無縫切換

　　橋接模式:

　　　　百度百科:橋接模式是將抽象部分與它的實現部分分離，使它們均可以獨立地變化。它是一種對象結構型模式，又稱爲柄體(Handle and Body)模式或接口(Interfce)模式。

　　　　1.一個接口,多個實現,以多態特性實現實現類能夠無縫切換的效果(好比使用List聲明對象時,arraylist和linkedlist能夠無縫切換),此爲橋接模式基礎(如實現了A功能)

　　　　2.使用A功能,不去繼承而是組合,就是持有對方對象,以這種方式調用方法

　　　　此爲橋接模式

　　組合模式:

　　　　菜鳥教程:組合模式（Composite Pattern），又叫部分總體模式，是用於把一組類似的對象看成一個單一的對象。組合模式依據樹形結構來組合對象，用來表示部分以及總體層次。這種類型的設計模式屬於結構型模式，它建立了對象組的樹形結構。

　　　　組合就是類內部持有對方對象,可是這裏的組合說的是模式,跟咱們日常組裝對象又不同

　　　　組合模式目的爲了統一簡單對象和複雜對象的處理方式,將複雜對象和簡單對象組合到一塊(統一處理),網上常常舉例文件夾和文件樹裝結構處理,文件夾就是複雜對象(由於內部還有東西),文件就是簡單對象

　　　　理解起來2個要點

　　　　1.統一,想要統一的處理方式,那就得實現相同接口,統一麼,對吧,因此簡單對象和複雜對象都要實現統一的接口

　　　　　　這個接口中寫統一的方法,方便調用,好比咱們聲明一個遍歷方法,文件夾實現就是進入內部繼續遞歸調用,文件就是直接輸出文件名

　　　　2.建立一個組合對象,由於咱們分別操縱文件夾或者文件,那就是各是各的,不能叫組合,因此,咱們須要這麼個對象,來統一操縱簡單對象和複雜對象

　　　　　　這個組合對象中要有一個list集合,裏面要能裝複雜對象,也要能裝簡單對象,這樣插入刪除方法就也能贊成了,一個list怎麼能裝兩種類型呢?由於他們都實現了一個接口,這樣咱們的list的泛型聲明成接口類型便可

　　　　到此,咱們就組合了2中對象,操縱時將數據先全放到這個組合對象裏面,而後經過組合對象的方法,統一處理,但其實內部會各自調用本身重寫的父類方法,實現統一調用

　　享元模式:

　　　　百度百科:享元模式是一種軟件設計模式。它使用共享物件，用來儘量減小內存使用量以及分享資訊給儘量多的類似物件；它適合用於只是因重複而致使使用沒法使人接受的大量內存的大量物件。一般物件中的部分狀態是能夠分享。常見作法是把它們放在外部數據結構，當須要使用時再將它們傳遞給享元。

　　　　享元模式與單例模式有殊途同歸之妙,目的都是爲了節省內存,對象只建立一次,以後每次都複用已生成的對象,與單例的區別是,單例中的對象是一個單獨的完整的對象,而享元模式中的對象分爲內部狀態和外部狀態兩種狀態,內外狀態組成一個完整的對象,內部狀態是共性,建立一次,以後複用,外部狀態每次都從新賦值,一對一單獨使用

　　　　享元,共享的就是內部狀態,外部狀態是不共享的,至關於局部單例

　　　　淺複製就相似因而享元的結果,內部共用同一個引用對象

行爲型模式

　　策略模式:　

　　　菜鳥教程:在策略模式（Strategy Pattern）中，一個類的行爲或其算法能夠在運行時更改。這種類型的設計模式屬於行爲型模式。在策略模式中，咱們建立表示各類策略的對象和一個行爲隨着策略對象改變而改變的 context 對象。策略對象改變 context 對象的執行算法。

　　　　其實就是if else ,將其中間的處理代碼抽出爲一個新的類(策略)[開始要聲明一個共同的策略接口,統一方法名],在調用時將不一樣的策略傳入便可,爲了統一調用,因此在中間還要有一個context上下文,其實就是調用方法的類,相似代理模式(只是相似),這個context就是個代理人,咱們不去直接調用策略的方法,而是經過context上下文去調用,實現統一調用

　　　　符合開閉原則,以後新增策略,直接新建一個策略類便可

　　模板方法模式:

　　　　菜鳥教程:在模板模式中，一個抽象類公開定義了執行它的方法的方式/模板。它的子類能夠按須要重寫方法實現，但調用將以抽象類中定義的方式進行。這種類型的設計模式屬於行爲型模式。

　　　　這個最簡單了,根據接口寫不一樣的實現,接口就至關於模板,子類實現就是最後的實現,咱們日常寫的MVC,ctrl層和service層,dao層,每層的接口和實現都是模板方法

這個理解有誤,多謝朋友犀利指出,這裏模板方法大體的樣子跟上面同樣,可是模板不僅是上面這麼簡單,通常狀況下,模板類是一個抽象類,好比:小汽車啓動須要點火,給油,這裏模板類會將啓動方法實現寫好,按順序調用點火,給油方法,而真正的點火給油方法抽象,留給子類實現,這樣纔是模板模式,好比restTemplat,jdbcTemplat,將模板(重複)方法抽出來,而具體的實現交給子類,抽出的方法才叫模板方法

　　觀察者模式:

　　　　百度百科:在此種模式中，一個目標物件管理全部相依於它的觀察者物件，而且在它自己的狀態改變時主動發出通知。這一般透過呼叫各觀察者所提供的方法來實現。此種模式一般被用來實現事件處理系統。

　　　　在被觀察者對象中,維護一個觀察者對象的列表,將觀察者加入列表稱爲註冊(監聽,訂閱),移除稱爲取消訂閱.被觀察者因爲持有觀察者列表,因此就能夠在必要的時候,能夠主動(被觀察者主動調用觀察者)遍歷調用觀察者的方法,這步稱爲通知,我我的理解這種方式相似於回調

　　迭代器模式:

　　　　百度百科:迭代器模式（Iterator），提供一種方法順序訪問一個聚合對象中的各類元素，而又不暴露該對象的內部表示。

　　　　目的是使遍歷和數據相互分開(解耦),因此實現起來就是兩個對象,一個遍歷數據的對象,一個集合對象自己,將集合對象自己傳入遍歷對象,就能夠調用遍歷對象方法來遍歷訪問集合數據中的每一個節點,核心其實仍是集合數據自己提供了訪問單個數據的方法,再用遍歷對象去調用這個方法

　　　　爲了規定統一的方法名,因此使用接口定義方法.

　　責任鏈模式:

　　　　百度百科:責任鏈模式是一種設計模式。在責任鏈模式裏，不少對象由每個對象對其下家的引用而鏈接起來造成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪個對象最終處理這個請求，這使得系統能夠在不影響客戶端的狀況下動態地從新組織和分配責任。

　　　　將處理請求的方法抽象爲類,而後組裝成一條鏈,前一個能獲取到下一個的對象

　　　　爲了調用方便,專有一個類用來自動組合這根鏈條,而後將請求內容傳入這個類,這個類中利用遞歸來處理這個請求,最後返回結果

　　命令模式:

　　　　命令（Command）模式的定義以下：將一個請求封裝爲一個對象，使發出請求的責任和執行請求的責任分割開。這樣二者之間經過命令對象進行溝通，這樣方便將命令對象進行儲存、傳遞、調用、增長與管理。

　　　　http://c.biancheng.net/view/1380.html

　　　　命令封裝爲一個對象,其中包括本身的執行方法,可是客戶端不直接調用命令對象,還有一個執行者對象,客戶端經過調用執行者對象,操縱對應命令對象,因此咱們須要將命令傳入執行者,執行者還得能調用命令對象方法.

　　備忘錄模式:

　　　　百度百科:備忘錄模式是一種軟件設計模式：在不破壞封閉的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態。這樣之後就可將該對象恢復到原先保存的狀態。

一個對象可能有10個屬性,其中有4個屬性可能須要隨時回滾以前狀態,咱們能夠將這4個屬性做爲一個狀態類,其實到此就能夠了,回滾數據時將狀態類中的值設置到對象中便可,可是這樣兩個對象耦合性過高,因此提出另外一個對象叫管理對象,將狀態對象交給管理對象管理,須要回滾狀態時,調用管理對象的方法將狀態設置到目標對象中便可