整體來說設計模式分為三大類:
創建型模式,共五種:工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。
結構型模式,共七種:適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
行為型模式,共十一種:策略模式、範本方法模式、觀察者模式、迭代子模式、責任鏈模式、指令模式、備忘錄模式、狀態模式、訪客模式、中介者模式、解釋器模式。
具體如下:
一、Singleton,單例模式:保證一個類別只有一個實例,並提供一個存取它的全域存取
點
二、Abstract Factory,抽象工廠:提供一個建立一系列相關或相互依賴物件的接口,
而無須指定它們的特定類別。
三、Factory Method,工廠方法:定義一個用於創建物件的接口,讓子類別決定實例化哪一個類,Factory Method 使一個類別的實例化延遲到了子類。
四、Builder,建造模式:將一個複雜物件的建構與他的表示相分離,使得同樣的建構過程可以創造不同的表示。
五、Prototype,原型模式:用原型實例指定建立物件的種類,並且透過拷貝這些原型來建立新的物件。
六、Iterator,迭代器模式:提供一個方法順序存取一個聚合物件的各個元素,而又不需要暴露該物件的內部表示。
七、Observer,觀察者模式:定義物件間一對多的依賴關係,當一個物件的狀態改變時,所有依賴它的物件都會被通知自動更新。
八、Template Method,模板方法:定義一個操作中的演算法的骨架,而將一些步驟延遲到子類別中,TemplateMethod 使得子類別可以不改變一個演算法的結構即可以重定義該演算法得某些特定步驟。
九、Command,命令模式:將一個請求封裝為一個對象,從而使你可以用不同的請求對客戶進行參數化,對請求排隊和記錄請求日誌,以及支援可撤銷的操作。
十、State,狀態模式:允許物件在其內部狀態改變時改變他的行為。物件看起來似乎改變了他的類別。
十一、Strategy,策略模式:定義一系列的演算法,把他們一個個封裝起來,並使他們可以互相替換,本模式使得演算法可以獨立於使用它們的客戶。
十二、China of Responsibility,職責鏈模式:使多個物件都有機會處理請求,從而避免請求的送發者和接收者之間的耦合關係
十三、Mediator,中介者模式:用一個中介物件封裝一些欄位的物件互動。
十四、Visitor,訪客模式:表示一個作用於某物件結構中的各元素的操作,它使你可以在不改變各元素類別的前提下定義作用於這個元素的新操作。
十五、Interpreter,解釋器模式:給定一個語言,定義他的文法的一個表示,並定義一
個解釋器,這個解釋器使用該表示來解釋語言中的句子。
十六、Memento,備忘錄模式:在不破壞物件的前提下,捕捉一個物件的內部狀態, 並在該物件之外保存這個狀態。
十七、Composite,組合模式:將物件組合成樹狀結構以表示部分整體的關係, Composite使得使用者對單一物件和組合物件的使用具有一致性。
十八、Facade,外觀模式:為子系統中的一組接口提供一致的介面,fa?ade 提供了一高層接口,這個接口使得子系統更容易使用。
十九、Proxy,代理模式:為其他物件提供一個代理程式以控制對這個物件的存取
二十、Adapter ,適配器模式:將一類的接口轉換成客戶希望的另外一個接口,Adapter 模式使得原本由於接口不相容而不能一起工作那些類可以一起工作。
二十一、Decrator,裝飾模式:動態地為一個物件增加一些額外的職責,就增加的功能來說,Decorator 模式相比生成子類別更加靈活。
二十二、Bridge,橋模式:將抽象部分與它的實作部分相分離,使他們可以獨立的變化。
二十三、Flyweight,享元模式
其實還有兩大類:並髮型模式和線程池模式。用一張圖片來整體描述一下:
#二、設計模式的六大原則
開閉原則就是說對擴展開放,對修改關閉。在程式需要進行拓展的時候,不能去修改原有的程式碼,而是要擴展原有程式碼,實現一個熱插拔的效果。所以一句話概括就是:為了讓程式的擴展性好,易於維護和升級。想要達到這樣的效果,我們需要使用介面和抽象類別等,後面的具體設計中我們會提到這一點。
不要存在多於一個導致類別變更的原因,也就是說每個類別應該實現單一的職責,如若不然,就應該把類別拆分。
里氏代換原則(Liskov Substitution Principle LSP)物件導向設計的基本原則之-」。里氏代換原則中說,
任何基類可以出現的地方,子類-定可以出現。LSP是繼承復用的基石,只有當衍生類可以替換掉基類,軟體單位的功能不受到影響時,基類才能真正被重複使用,而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基底類別與子類別的繼承關係就是抽象化的具體實現,所以里氏代換原則是對實現抽象化的具體步驟的規範。一FromBaidu
百科
歷史替換原則中,子類別對父類別的方法盡量不要重寫和重載。因為父類別代表了定義好的結構,透過這個規範的介面與外界交互,子類別不應該隨便破壞它。
這個是開閉原則的基礎,具體內容:面向介面編程,依賴抽象而不依賴具體。寫程式時用到具體類別時,不與具體類別交互,而與具體類別的上層介面交互。
這個原則的意思是:每個接口中不存在子類別用不到卻必須實現的方法,如果不然,就要將接口拆分。使
用多個隔離的接口,比使用單個接口(多個接口方法集合到-一個的介面)要好。
就是說:一個類別對自己依賴的類別知道的越少越好。也就是說無論被依賴的類別多麼複雜,都應該將邏輯封裝在方法的內部,透過public方法提供給外部。這樣當被依賴的類別變化時,才能最小的影響該類別。
#最少知道原則的另一個表達方式是:只與直接的朋友通信。類別之間只要有耦合關係,就叫朋友關係。耦
#合分為依賴、關聯、聚合、組合等。我們稱出現為成員變數、方法參數、方法傳回值中的類別為直接朋友。局部變數、臨時變數則不是直接的朋友。我們要求陌生的類別不要作為局部變數出現在類別中。
原則是盡量先使用合成/聚合的方式,而不是使用繼承。
從這一塊開始,我們詳細介紹Java中23種設計模式的概念,應用場景等情況,並結合他們的特點及設計模式的原則進行分析。
首先,簡單工廠模式不屬於23涉及模式,簡單工廠一-般分為:普通簡單工廠、多方法簡單工廠、靜態方法簡單工廠。
簡單工廠模式模式分為三種:01、普通
就是建立-一個工廠類,對實現了同一介面的一些類進行實例的建立。首先看下關係圖:
舉例如下: (我們舉一一個發送郵件和簡訊的例子)首先, 創建二者的共同介面:
public interface Sender { public void Send(); }
其次,建立實作類別:
public class MailSender implements Sender { @Override public void Send() { System.out.println("this is mailsender!"); } } public class SmsSender implements Sender { @Override public void Send() { System.out.println("this is sms sender!"); } }
最後,建立工廠類別:
public class SendFactory { public Sender produce(String type){ if ("mail" .equals(type) { return new MailSender( ); }else if("sms" .equals(type)){ return new SmsSender(); }else{ System. out . println("请输入正确的类型!"); return null;) } }
我們來測試下方:
public class FactoryTest { public static void main(String[] args) { SendFactory factory = new SendFactory(); Sender sender = factory.produce("sms"); sender.Send(); } }
輸出: this is sms sender!
02、多個方法
是對普通工廠方法模式的改進,在普通工廠方法模式中,如果傳遞的字串出錯,則不能正確創建對象,而多個工廠方法模式是提供多個工廠方法, 分別建立物件。關係圖:
將上面的程式碼做下修改,改動下SendFactory類別就行,如下:
public class SendFactory { public Sender produceMail(){ return new MailSender(); } public Sender produceSms(){ return new SmsSender(); } }
測試類別如下:
public class FactoryTest{ public static void main(String[] args) { SendFactory factory = new SendFactory( ); Sender sender = factory.produceMail(); sender.Send(); } }
輸出: this is mailsender!
相關文章:
#以上是Java 之 23 種設計模式概述與6大設計模式原則的詳細內容。更多資訊請關注PHP中文網其他相關文章!