你觉得外观模式和代理模式的联系和区别是什么?_GoF23种设计模式
生活随笔
收集整理的這篇文章主要介紹了
你觉得外观模式和代理模式的联系和区别是什么?_GoF23种设计模式
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
UML
- 泛化（繼承非抽象類）：帶空心三角形的直線表示
- 實現（繼承抽象類，類實現接口）：帶空心三角形的虛線表示
- 依賴：類與類之間最弱的關系，依賴可以簡單的理解一個類使用了另一個類：帶箭頭的虛線表示依賴
- 關聯：一個類和另一類有聯系：帶箭頭的實線表示
- 聚合：表示整體與部分的關系，但是部分可以脫離整體而存在：帶空心菱形的直線加箭頭表示，has-a關系
- 組合：部分和整體的關系，但是部分存活周期受到整體的影響，若整體不存在則部分也將不存在。此時部分需在整體的構造方法中創建：帶實心菱形的直線加箭頭表示。
- 關系所表現的強弱程度依次為：組合>聚合>關聯>依賴；
軟件設計七大原則
- 開閉原則:對擴展開放，對修改封閉。在程序需要進行拓展的時候，不能去修改原有的代碼，而是要擴展原有代碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程序的擴展性好，易于維護和升級。
- 單一職責原則:不要存在多于一個導致類變更的原因，也就是說每個類應該實現單一的職責，否則就應該把類拆分。
- 里氏替換原則:任何基類可以出現的地方，子類一定可以出現。
- 依賴倒置原則:面向接口編程，依賴于抽象而不依賴于具體。寫代碼時用到具體類時，不與具體類交互，而與具體類的上層接口交互。
- 接口隔離原則:每個接口中不存在子類用不到卻必須實現的方法，如果不然，就要將接口拆分。使用多個隔離的
- 迪米特法則:一個類對自己依賴的類知道的越少越好。無論被依賴的類多么復雜，都應該將邏輯封裝在方法的內部，通過public方法提供給外部。這樣當被依賴的類變化時，才能最小的影響該類。接口，比使用單個接口（多個接口方法集合到一個的接口）要好。
- 合成復用原則:盡量首先使用合成/聚合的方式，而不是使用繼承。
創建型
工廠方法模式
定義：定義一個創建對象的接口，但讓實現這里接口的類來決定實例化那個類，工廠方法讓類的實例化推遲到子類中進行
優點
- 用戶只需要關心所需要產品的工廠，無需關心創建細節
- 加入新產品符合開閉原則，提高擴展性
缺點
- 類的個數容易過多，增加復雜度
- 增加了系統的抽象性和理解難度
適用場景
- 創建對象需要大量重復的代碼
- 應用層不依賴于產品類實例如何被創建、實現等細節
- 一個類通過其子類來指定創建那個對象
抽象工廠模式
定義：抽象工廠模式提供一個創建一系列相關或相互依賴對象的接口
優點
- 具體產品在應用層代碼隔離，無需關心創建細節
- 將一個系列的產品族統一到一起創建
缺點
- 規定了所有可能被創建的產品集合，產品族中擴展新的產品困難，需要修改抽象工廠的接口
- 增加了系統的抽象性和理解難度
適用場景
- 應用層不依賴于產品類實例如何被創建、實現等細節
- 強調一系列相關的產品對象（屬于同一產品族）一起使用創建對象需要大量重復代碼
- 提供一個產品類的庫，所有產品以同樣的接口出現，從而使應用層依賴于具體實現
單例模式
注意：私有構造器、線程安全、延遲加載、序列化和反序列化安全、反射、cpu亂序執行優化
定義：保證一個類僅有一個實例，并提供一個全局訪問點
優點
- 在內存里只有一個實例，減少了內存開銷
- 可以避免對資源的多重占用
- 設置全局訪問點，嚴格控制訪問
缺點
- 沒有接口、擴展困難
適用場景
- 想確保任何情況下都絕對只有一個實例
建造者模式
定義：將一個復雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示
優點
- 封裝性好，創建和使用隔離
- 擴展性好、建造類之間獨立、一定程度上解耦
缺點
- 會產生多余的Builder對象（使用Lombok的注解可以避免）
- 產品內部發生變化，建造者都要修改，成本較大（Lombok可以解決）
適用場景
- 如果一個對象有非常多的屬性
- 想把復雜對象的創建和使用分離
原型模式
定義：指定原型實例指定創建對象的種類，并且通過拷貝這些原型創建新的對象
優點
- 比直接new一個對象性能高
- 簡化創建過程
缺點
- 必須配備克隆方法
- 對克隆復雜對象或對克隆出的對象進行復雜改造時，容易引入風險
- 深拷貝、淺拷貝要運用得當
適用場景
- 類初始化消耗較多資源
- new產生的一個對象需要非常繁瑣的過程（數據準備、訪問權限等）
- 構造函數比較復雜
- 循環體中產生大量對象時
行為型
適配器模式
定義：將一個類的接口轉換成客戶期望的另一個接口
優點
- 能提高類的透明性和復用，現有的類復用但不需要改變
- 目標類和適配器類解耦，提高程序擴展性
- 符合開閉原則
缺點
- 適配器編寫過程需要全面考慮，可能會增加系統的復雜性
- 增加系統代碼可讀的難度
適用場景
- 已經存在的類，它的方法和需求不匹配時（方法結果相同或相似）
- 不是軟件設計階段考慮的設計模式，是隨著軟件維護，由于不同產品、不同廠家造成功能類似而接口不同情況下的解決方案
裝飾器模式
定義：在不改變原有對象的基礎之上，將功能附加到對象上，提供了比繼承更有彈性的替代方案
優點
- 繼承的有力補充，比繼承靈活，不改變原有對象的情況下給一個對象擴展功能
- 通過使用不同裝飾類以及這些裝飾類的排列組合，可以實現不同效果
- 符合開閉原則
缺點
- 會出現更多的代碼，更多的類，增加程序復雜性
- 動態裝飾時，多層裝飾時會更復雜
適用場景
- 擴展一個類的功能或者添加附加職責
- 動態的給一個對象添加功能，這些功能可以再動態的撤銷
代理模式
定義：為其他對象提供一種代理，以控制對這個對象的訪問
優點
- 代理模式能將代理對象與真實被調用的目標對象分離
- 一定程度上降低了系統的耦合度，擴展性好
- 保護目標對象
- 增強目標對象
缺點
- 代理模式會造成系統設計中類的數目增加
- 在應用層和目標對象增加一個代理對象，會造成請求處理速度變慢
- 增加系統的復雜度
適用場景
- 保護目標對象
- 增強目標對象
外觀模式
定義：提供了一個統一的接口，用來訪問子系統中的一群接口
優點
- 簡化了調用過程，無需深入了解子系統，防止帶來風險
- 減少系統依賴，松散耦合
- 更好的劃分訪問層次
- 符合迪米特法則，即最少知道原則
缺點
- 增加子系統、擴展子系統行為容易引入風險
適用場景
- 子系統越來越復雜，增加增加外觀模式提供簡單調用接口
- 構建多層系統結構，利用外觀對象作為每層的入口，簡化層間的調用
橋接模式
定義：將抽象部分與具體實現部分分離，使他們可以獨立變化，通過組合的方式建立兩個類之間聯系，而不是繼承
優點
- 分離抽象部分和具體實現部分
- 提高了系統的可擴展性
- 符合開閉原則
- 符合合成復用原則
缺點
- 增加了系統的理解與設計難度
- 需要正確地識別出系統中兩個獨立變化的維度
適用場景
- 抽象和具體之間增加更多的靈活性
- 一個類存在兩個（或多個）獨立變化的維度，且這兩個（或多個）維度都需要獨立進行擴展
- 不希望使用繼承，或者因為多層繼承導致系統類的個數劇增
組合模式
定義：將對象組合成樹型結構以表示“部分-整體”的層次結構
優點
- 清除地定義分層次的復雜對象，表示對象的全部或部分層次
- 讓應用層忽略了層次的差異，方便對整個層次結構進行控制
- 簡化應用層代碼
- 符合開閉原則
缺點
- 限制類型時會比較復雜
- 使設計變得更加抽象
適用場景
- 希望應用層可以忽略組合對象與單個對象的差異時
- 處理一個樹型結構時
享元模式
定義：提供了減少對象數量從而改善應用所需的對象結構的方式
優點
- 減少對象的創建，降低內存中對像的數量，降低系統的內存，提高效率
- 減少內存之外的其他資源占用
缺點
- 關注內/外部狀態、關注線程安全問題
- 使系統、程序的邏輯復雜化
適用場景
- 常常應用于系統底層的開發，以便解決系統的性能問題
- 系統有大量相似對象、需要緩沖池的場景
結構型
策略模式
定義：定義了算法家族，分別封裝起來，讓它們之間可以相互替換，此模式讓算法的變化不會影響到使用算法的用戶
優點
- 開閉原則
- 避免使用多重條件轉移語句
- 提高算法的保密性和安全性
缺點
- 應用層必須知道所有的策略類，并自行決定使用哪一個策略類
- 產生很多策略類
適用場景
- 系統有很多類，而他們的區別僅僅在于他們的行為不同
- 一個系統需要動態的在幾種算法中選擇一種
模板方法模式
定義：定義了一個算法的骨架，并允許子類為一個或多個步驟提供實現
優點
- 提高復用性
- 提高擴展性
- 符合開閉原則
缺點
- 類數目增加
- 增加了系統實現的復雜度
- 繼承關系自身缺點，如果父類添加新的抽象方法，所有子類都要改一遍
適用場景
- 一次性實現一個算法的不可變的部分，并將可變的行為留給子類來實現
- 各子類中公共的行為被提取出來并集中到一個公共父類中，從而避免代碼重復
觀察者模式
定義：定義了對象之間的一對多依賴，讓多個觀察者對象同時監聽某一個主題對象，當主題對象發生變化時，它的所有依賴者（觀察者）都會收到通知并更新
優點
- 觀察者和被觀察者之間建立一個抽象的耦合
- 觀察者模式支持廣播通信
缺點
- 觀察者之間有過多的細節依賴、提高時間消耗及程序復雜度
- 使用要得當，要避免循環調用
適用場景
- 關聯行為場景，建立一套觸發機制
迭代器模式
定義：提供一種方法，順序訪問一個集合對象中的各個元素，而又不暴露改對象的內部表示
優點
- 分離了集合對象的遍歷行為
缺點
- 類的個數成對增加
適用場景
- 訪問一個集合對象的內容而無需暴露它的內部表示
- 為遍歷不同的集合結構提供一個統一的接口
責任鏈模式
定義：為請求創建一個接收此次請求對象的鏈
優點
- 請求的發送者和接收者解耦
- 責任鏈可以動態組合
缺點
- 責任鏈太長或者處理時間過長，影響性能
- 責任鏈有可能過多
適用場景
- 一個請求的處理需要多個對象當中的一個或幾個協作處理
命令模式
定義：將請求封裝成對象，以便使用不同的請求
優點
- 降低耦合
- 容易擴展新命令或一組命令
缺點
- 命令的無限擴展會增加類的數量，提高系統實現復雜度
適用場景
- 請求調用者和請求接受者需要解耦，使調用者和接受者不直接交互
- 需要抽象出等待執行的行為
備忘錄模式
定義：保存一個對象的某個狀態，以便在適當的時候恢復對象
優點
- 為用戶提供一種可恢復機制
- 存檔信息的封裝
缺點
- 資源占用
適用場景
- 保存及恢復數據相關業務場景
- 后悔的時候，即想恢復到之前的狀態
狀態模式
定義：允許一個對象在其內部狀態改變時，改變它的行為
優點
- 將不同的狀態隔離
- 把各種狀態的轉換邏輯，分布到State的子類中，減少相互間依賴
- 增加新的狀態非常簡單
缺點
- 狀態多的業務場景導致類數目增加，系統變復雜
適用場景
- 一個對象存在多個狀態（不同狀態下行為不同），且狀態可相互轉換
訪問者模式
定義：封裝作用于某數據結構（如List/Set/Map等）中的各個元素的操作
優點
- 增加新的操作很容易，即增加一個新的訪問者
缺點
- 增加新的數據結構困難
- 具體元素變更比較麻煩
適用場景
- 一個數據結構如（List/Set/Map等）包含很多類型對象
- 數據結構與數據操作分離
中介者模式
定義：定義一個封裝一組對象如何交互的對象
優點
- 將一對多轉化成了一對一，降低程序復雜度
- 類之間解耦
缺點
- 中介者過多導致系統復雜
適用場景
- 系統中對象之間存在復雜的引用關系，產生的相互依賴關系結構混亂且難以理解
- 交互的公共行為，如果需要改變行為則可以增加新的中介者類
解釋器模式
定義：給定一個語言，定義它的文法的一種表示，并定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子
優點
- 語法由很多類表示，容易改變及擴展此“語言”
缺點
- 當語法規則數目太多時，增加了系統復雜度
適用場景
- 某個特定類型問題發生頻率足夠高
總結
以上是生活随笔為你收集整理的你觉得外观模式和代理模式的联系和区别是什么?_GoF23种设计模式的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 期刊投稿状态_追踪期刊在线系统投稿状态（
- 下一篇： asp.net 将bmp格式图片怎么转换