Bridge 在接口和實現中都有接口層次結構時，使用 Bridge 設計模式將接口與實現分離，並對客戶端程序隱藏實現細節。 根據 GoF 橋的設計模式是：將抽象與其實現分離，以便兩者可以獨立變化。 將抽象及其實現分開，並為抽象和實現者開發單獨的繼承結構。抽像是接口或抽像類，同樣實現者是接口或抽像類。抽象包含對實現者的引用。抽象的孩子被稱為精煉抽象，實現者的孩子是具體的實現者。由於我們可以在抽像中更改對實現者的引用，因此我們可以在運行時更改抽象的實現者。但是，對實現者的更改不會影響客戶端代碼。 Bridge 的目的是將抽象和實現放入兩個不同的類層次結構中，以便兩者都可以獨立擴展。 Bridge 幫助兩個不兼容的 類一起工作。但是 Bridge 通過創建兩個不同的層次結構來分離抽象和實現。

Facade 為子系統中的一組 interface 提供統一的入口。Facade Pattern 定義了一個更高級別的接口，使子系統更易於使用 Facade 並沒有封裝子系統類或接口；它只是為其功能提供了一個簡化的界面。 此外，客戶端可以直接訪問這些類。它仍然為可能需要它的客戶公開系統的全部功能。簡而言之，它只是為子系統的複雜接口提供了一層，使其更易於使用。 外觀設計模式是促進鬆散耦合的其他設計模式之一。它強調了設計中最重要的一個方面，即抽象。通過隱藏它背後的複雜性並暴露一個簡單的接口，它實現了抽象。 Facade 和 Adapter 一樣可以封裝多個類，但是 Facade 使用接口來簡化複雜接口的使用，而 Adapter 用於將接口轉換為客戶端期望的接口。 在抽象方面，中介者設計模式可能看起來與外觀設計模式非常相似。Mediator 以類似於外觀模式的方式抽象子系統的功能。然而，在中介者模式的實現中，子系統或對等點的組件都知道中介者並與之交互。但是在外觀模式的情況下，子系統不知道外觀的存在。只有外觀與子系統對話。

Flyweight Flyweight 中，我們重複使用對象，而不是創建大量相似的對象。我們可以使用它來減少內存需求和實例化時間以及相關成本。 在我們應用 Flyweight 之前，我們需要考慮以下因素： 如果應用程序中所需的對像數量巨大。 如果對象創建佔用大量內存並且也可能很耗時。 太多的對象會降低應用程序的性能。顯然，太多的對象可能會消耗更大的內存。此外，它們可能會降低應用程序的速度，甚至可能導致內存不足問題。 在應用程序中控制它。當我們有很多相似的對象並且池中的兩個對象之間沒有太多差異時，尤其如此。 有時，應用程序中的對象可能具有很大的相似性並且屬於相似類型（此處的相似類型意味著它們的大多數屬性具有相似的值，並且只有少數屬性值不同）。如果它們也是要創建的重物，應用程序開發人員應該控制它們。否則，它們可能會消耗大量內存並最終減慢整個應用程序的速度。

Proxy Proxy pattern 為另一個對象 create a representative object that controls access to another object。 事實上，Proxy pattern 是用來創建一個代表對象來控制對另一個對象的訪問。成本高或需要保護以至於存取消費較大。

Composite Composite 讓客戶可以統一處理單個對象和對象的組合，這就是 Composite Pattern 的意圖。 在復合模式中，存在一個樹結構，可以在葉子和節點上執行相同的操作。樹中的節點是可以有孩子的類。節點類是“複合”類。樹上的葉子是沒有孩子的“原始”類。 組合的子節點可以是葉子或其他組合。 葉類和復合類共享一個通用的 “Composite” interface，該接口定義了可以在葉和復合上執行的通用操作。當對組合執行操作時，將對組合的所有子節點執行此操作，無論它們是葉子還是組合。因此，複合模式可用於對組成樹的對象執行常見操作。

Adapter 將一個類別的介面 轉換成另一個類別的介面供客戶使用 讓介面不相容的類別可以合作 有時，可能會出現兩個對像不適合在一起的情況，或者在代碼中更改第 3 方 API 時，可能會出現這種情況。 顯然，這是由於兩個不適合在一起的對象的接口不兼容造成的。

Prototype 一種對象創建機制。 假設有一個從 DB 加載數據的對象。現在，我們需要在程序中多次修改這些數據。因此，使用 new 關鍵字創建對象並再次從數據庫中加載所有數據並不是一個好主意。因此，更好的方法是將現有對象 clone 為新對象，然後進行數據操作。 但是，原型設計模式要求您正在復制的對象應提供複製功能。顯然，它不應該由任何其他類來完成。但是，是使用 Object 屬性的淺拷貝還是深拷貝取決於需求，這是一個設計決定。

Builder 對象構造的細節，實例化和初始化構成對象的組件，都保存在對像中，通常作為其構造函數的一部分。這種類型的設計將對象構造過程與構成對象的組件緊密聯繫在一起。但是，只要構造對像簡單，對象構造過程明確，並且總是產生對象的相同表示，這種方法就適用。 此外，當被創建的對像很複雜並且構成對象創建過程的一系列步驟可以以不同的方式實現時，這種設計可能無效。因此，產生對象的不同表示。因為構造過程的不同實現都保存在對像中，所以對象可能變得龐大（構造膨脹）並且模塊化程度較低。隨後，添加新實現或更改現有實現需要更改現有代碼。 Builder 的目的是將復雜對象的構造與其表示分離，以便相同的構造過程可以創建不同的表示。這種類型的分離減小了對象的大小。該設計變得更加模塊化，每個實現都包含在不同的構建器對像中。因此，添加一個新的實現（即添加一個新的構建器）變得更容易了。此外，對象構造過程變得獨立於構成對象的組件。這提供了對對象構造過程的更多控制。 它指定了一個抽象接口，用於創建 Product 對象的各個部分。構建器模式建議將構建邏輯從對像類移到一個單獨的類，稱為構建器類。但是，可以有多個這樣的構建器類，每個構建器類對於構建對象的一系列步驟都有不同的實現。此外，每個構建器實現都會導致對象的不同表示。 ConcreteBuilder 通過實現 Builder 接口來構造和組裝產品的各個部分。 定義並跟踪它創建的表示。 提供用於檢索產品的接口。 Director 它使用 Builder 接口構造一個對象。Builder 模式建議使用稱為 Director 的專用對象，它負責調用構建最終對象所需的不同構建器方法。此外，不同的客戶端對象可以利用 Director 對象來創建所需的對象。一旦構造了對象，客戶端對象就可以直接向構造器請求完整構造的對象。為了方便這個過程，可以在公共Builder接口中聲明一個新方法getObject()，由不同的具體builder實現。

Factory 一個具有多個子類的父類別並且基於輸入，我們需要返回其中一個子類時，使用工廠設計模式。這種模式將類從客戶端程序實例化到工廠類的責任。 工廠模式中的超類可以是 interface，也可以是 abstract class，也可以是普通的 Java class。 public interface ICellPhone { public void open(); public void close(); public void call(); } public class ApplePhone implements ICellPhone { @Override public void open() { System.

Singleton 確保在 java 虛擬機中只存在該類的一個實例。單例類必須提供一個全局訪問點來獲取類的實例。 一個類應該只允許一個實例， 應該允許全局訪問該單個實例。 用於限制從其他類實例化類的私有構造函數。 同一類的私有靜態變量，是該類的唯一實例。 公共靜態方法，返回類的實例，這是外部世界獲取單例類實例的全局訪問點。 Reflection, Clone, 序列化/反序列化 違反 Singleton public static Singleton instance= new Singleton(); private Singleton() { System.