天天看點

Java程式員必須掌握的15個設計模式,特點和使用場景彙總整理!

作者:Code404

設計模式是一種廣泛使用的程式設計思想,它是一種用于解決特定問題的經驗性方法,提供了一套通用的解決方案,可用于不同的應用場景,可以幫助我們解決常見的問題并提高代碼的可重用性和可維護性。

設計模式分為三類:建立型設計模式、結構型設計模式和行為型設計模式。

一、建立型設計模式

建立型設計模式用于封裝對象的建立過程,它們可以幫助我們在不暴露對象建立過程的情況下建立對象。以下是常見的建立型設計模式:

1. 工廠方法模式

工廠方法模式(Factory Method Pattern)是一種用于封裝對象建立過程的模式。它定義了一個建立對象的接口,但讓子類決定執行個體化哪個類。工廠方法使得一個類的執行個體化延遲到其子類。

優點:子類可以在運作時決定建立的對象類型,而且可以避免用戶端與具體類耦合。同時,它也很容易增加新的産品線。

使用場景:當我們需要隐藏對象建立過程,并讓用戶端通過抽象接口來建立對象時,可以考慮使用工廠方法模式。例如,當我們需要建立不同的消息對象時,可以使用工廠方法模式來建立消息對象。

2. 抽象工廠模式

抽象工廠模式(Abstract Factory Pattern)是一種用于建立相關或獨立對象族的模式。它提供了一種接口,該接口可以建立一系列産品,但不需要指定具體的産品類。

優點:它可以隐藏産品的具體實作,以及如何建立這些産品。同時,它也使得用戶端可以獨立于具體的産品建立過程。

使用場景:當我們需要建立一系列相關或獨立的對象時,可以考慮使用抽象工廠模式。例如,當我們需要建立一系列不同類型的手機和電視時,可以使用抽象工廠模式。

3. 單例模式

單例模式(Singleton Pattern)是一種用于限制類的執行個體化次數的模式。它保證一個類隻有一個執行個體,并提供全局通路點。

優點:它可以節省系統資源,并且可以避免多個對象之間的沖突。

使用場景:當一個類隻需要一個執行個體時,可以考慮使用單例模式。例如,當一個類需要負責管理應用程式的配置資訊時,可以使用單例模式。

4. 建造者模式

建造者模式(Builder Pattern)是一種用于封裝複雜對象建構過程的模式。它将對象的建構和表示分離,使得相同的建構過程可以建立不同的表示。

優點:它可以靈活地建立對象,并且可以避免重複的建構過程。同時,它也很容易擴充,因為每個部件都是獨立的。

使用場景:當我們需要建構一些複雜的對象時,可以考慮使用建造者模式,例如,當我們需要建立一個電子商品時,可以使用建造者模式來建立商品對象。

5. 原型模式

原型模式(Prototype Pattern)是一種用于建立對象的模式,它通過複制現有的對象來建立新的對象。原型模式通過克隆現有對象來建立新對象,而不是通過調用構造函數。

優點:它可以減少對象建立的開銷,并且可以最大限度地利用已有對象。同時,它還可以避免構造函數的限制。

使用場景:當我們需要建立大量相似的對象時,可以考慮使用原型模式,例如,當我們需要建立多個相似的線圖或柱圖對象時,可以使用原型模式來複制現有的對象。

二、結構型設計模式

結構型設計模式用于将對象組合成更大、更複雜的結構,以便于更好地組織代碼。以下是常見的結構型設計模式:

1. 擴充卡模式

擴充卡模式(Adapter Pattern)是一種用于将不相容的對象轉換為相容對象的模式。它通過使一個類的接口适用另一個接口來完成這個過程。擴充卡模式既可以是類擴充卡,也可以是對象擴充卡。

優點:它可以使得原本不相容的對象可以協同工作。同時,它還可以減少代碼的備援。

使用場景:當我們需要将一個類的接口轉換為其他類所期望的接口時,可以考慮使用擴充卡模式。例如,當我們需要将一個第三方類庫的接口轉換為我們的應用程式所期望的接口時,可以使用擴充卡模式。

2. 橋接模式

橋接模式(Bridge Pattern)是一種用于将抽象和實作分離的設計模式。它通過使用一個中間類來連結抽象和實作,使得它們可以獨立地變化。

優點:它可以減少類之間的耦合,并且可以使得抽象和實作可以獨立地進行變化。

使用場景:當我們需要将抽象和實作分離,并且需要對它們進行獨立的變化時,可以考慮使用橋接模式。例如,當我們需要将一個筆刷分為硬筆刷和軟筆刷時,可以使用橋接模式來實作。

3. 組合模式

組合模式(Composite Pattern)是一種用于将對象組成樹形結構的模式。它将單個對象群組合對象中的對象統一看作一個對象,這樣使用者無需了解其中細節即可處理它們。

優點:它可以簡化用戶端代碼,并且可以使得增加或删除節點時非常容易。

使用場景:當我們需要組合單個對象群組合對象時,可以使用組合模式。例如,當我們需要建立一個菜單時,可以使用組合模式來組合不同的菜單項。

4. 裝飾器模式

裝飾器模式(Decorator Pattern)是一種用于動态地給對象添加職責的模式。它在不改變原有類的基礎上,通過将對象包裝在一個裝飾器類中,來實作對對象功能的擴充。

優點:它可以在運作時動态地擴充一個對象的職責,而不需要修改源代碼。同時,它也很容易擴充,因為每個裝飾器都是獨立的。

使用場景:當我們需要在運作時動态地擴充一個對象的功能時,可以考慮使用裝飾器模式。例如,當我們需要給某個對象動态地添加日志、驗證或緩存等功能時,可以使用裝飾器模式。

5. 外觀模式

外觀模式(Facade Pattern)是一種用于隐藏複雜子系統的複雜性,并提供一個簡單接口的模式。外觀模式将複雜的子系統組合在一起,并提供一個簡單接口來簡化用戶端調用。

優點:它可以簡化用戶端代碼,并且可以隔離複雜子系統的實作細節。

使用場景:當我們需要對複雜子系統進行封裝,并提供一個簡單接口時,可以考慮使用外觀模式。例如,當我們需要對資料庫進行操作時,可以使用外觀模式來封裝資料庫通路過程。

三、行為型設計模式

行為型設計模式關注對象之間的通信和協作。以下是常見的行為型設計模式:

1. 政策模式

政策模式(Strategy Pattern)是一種用于定義一系列算法,以及提供一種在運作時可以切換算法的方式的模式。該模式允許算法獨立于用戶端而變化。

優點:它可以很容易地替換算法,并且可以避免使用大量的條件語句。同時,它也可以提高代碼的可擴充性和可維護性。

使用場景:當我們需要在運作時根據不同的需求選擇不同的算法時,可以考慮使用政策模式。例如,當我們需要根據不同的使用者類型計算不同的折扣時,可以使用政策模式來實作。

2. 觀察者模式

觀察者模式(Observer Pattern)是一種用于對象之間的一對多依賴關系的模式。當一個對象的狀态發生改變時,所有依賴它的對象都會得到通知并自動更新狀态。

優點:它可以使得對象之間的耦合度更低,并且可以提高代碼的可維護性和可擴充性。

使用場景:當我們需要建立對象之間一對多的依賴關系時,可以考慮使用觀察者模式。例如,當我們需要實作一個簡單的消息通知系統時,可以使用觀察者模式來實作。

3. 指令模式

指令模式(Command Pattern)是一種将請求封裝成對象的模式,以便于存儲、傳遞和使用。指令模式将請求接收者和請求發送者從彼此解耦,使得請求可以被重複執行、取消和排隊。

優點:它可以對請求進行操作,并且可以靈活地添加新的指令,同時也可以很容易地撤銷和重做操作。

使用場景:當我們需要對操作進行封裝,并且需要支援撤銷和重做操作時,可以考慮使用指令模式。例如,當我們需要實作一個簡單的文本編輯器時,可以使用指令模式來實作。

4. 疊代器模式

疊代器模式(Iterator Pattern)是一種提供一種方法順序通路聚合對象中各個元素的模式。疊代器模式将集合和周遊操作分離開來,使得可以對集合進行不同方式的周遊,而無需改變集合本身的結構。

優點:它可以隔離周遊算法和資料結構,并且可以簡化周遊代碼。

使用場景:當我們需要周遊一系列對象時,可以考慮使用疊代器模式。例如,當我們需要對一個圖像集合進行周遊時,可以使用疊代器模式來實作。

5. 責任鍊模式

責任鍊模式(Chain of Responsibility Pattern)是一種用于将多個處理對象連成一條鍊,并依次處理請求的模式。每個處理對象都可以決定是否處理請求,以及是否将請求傳遞給下一個處理對象。

優點:它可以避免用戶端和處理對象之間的耦合,同時也可以提高代碼的可擴充性和可維護性。

使用場景:當我們需要将請求發送給多個處理對象,并且讓它們依次處理請求時,可以考慮使用責任鍊模式。例如,當我們需要處理一個訂單時,可以使用責任鍊模式來處理訂單狀态的變化。

總結

本文介紹了三種常見的設計模式:建立型設計模式、結構型設計模式和行為型設計模式。這些模式都有各自的優點和使用場景,可以幫助開發人員更好地組織代碼,并提高代碼的可擴充性和可維護性。在實際開發過程中,我們應該根據不同的需求選擇不同的模式,并靈活地使用它們。

在後續的文章合集中,我會詳細介紹每一種設計模式的原理及其使用場景,請關注我的後續文章。【一天一個設計模式(一):觀察者模式,松耦合的Java代碼利器】

對于本文中整理的設計模式,不知道你有沒有什麼看法,歡迎在評論區裡留言。如果你對我的文章内容感興趣,請點選關注,謝謝支援! [謝謝][謝謝][謝謝]

繼續閱讀