模板方法模式及設計模式總結

時間 2019-11-07

標籤模板方法模式設計總結简体版

原文原文鏈接

模板方法模式及設計模式總結

定義

模板方法模式是基於繼承的代碼複用技術。html

經過繼承，讓父類成爲子類的模板，全部重複的代碼都應該上升到父類去，而不是讓每一個子類都去重複。java

使用場景

當咱們要完成在某一細節層次一致的一個過程或一系列步驟，但其個別步驟在更詳細的層次上的實現可能不一樣時，一般考慮使用模板方法模式來處理。git

模板方法模式是很經常使用的設計模式，在類的繼承中每每會用到這個模式。github

Sample

mosby Model-View-Presenter library算法

乍一看可能有些複雜，實際上只有一個方法 createPresenter() 將建立對應的 Presenter 的任務交給子類去處理。提升了父類 MvpActivity 的複用性。而將全部子類中共同的邏輯：管理 Presenter 和 View 之間的聯繫，提到父類中處理。增長了代碼的可維護性。設計模式

優勢

封裝不可變的部分，擴展可變的部分
將公共代碼提取到基類中，便於維護

缺點

每個不一樣的實現都須要一個子類來實現。函數

注意事項

Java 中的模板方法，爲了防止基類中定義的方法實現被意外修改，通常會將在基類中實現的方法設置爲 final .工具

你將在真實世界代碼中看到模板方法模式的許多變體，不要期待它們全都是一眼就能夠被認出的。設計

對比

策略模式和模板方法模式都封裝算法，一個用組合，一個用繼承。代理

策略模式定義一個算法家族，並讓這些算法能夠互換，每一個算法都被封裝起來，因此客戶能夠輕易使用不一樣算法。

模板方法模式定義一個算法大綱，由子類決定其中某些步驟的內容，這樣一來算法中的個別步驟能夠有不一樣的實現細節，可是算法的結構依然維持不變。

好萊塢原則

別調用（打電話給）咱們，咱們會調用（打電話給）你。

高層組件對待低層組件的方式是「別調用咱們，咱們會調用你」。父類控制算法的大綱，只有在須要子類實現某個方法時，才調用子類。子類只是簡單用來提供一些實現細節。

並非說低層組件徹底不能調用高層組件中的方法，咱們要作的是避免讓高層和低層組件之間有明顯的環狀依賴。

總結

建立型模式

抽象工廠：提供一個建立一系列或相關依賴對象的接口，而無需指定它們具體的類。

建造者模式：將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示。

工廠方法：定義一個用於建立對象的接口，讓子類決定實例化哪個類。

原型模式：用原型實例指定建立對象的種類，而且經過拷貝這些原型建立新的對象。

單例模式：保證一個類只有一個實例，而且提供一個訪問它的全局訪問點。

建立型模式隱藏了這些類的實例是如何被建立和放在一塊兒，整個系統關於這些對象所知道的是由這些抽象類所定義的接口。建立型模式在建立了什麼，誰建立它，它是怎麼被建立的，以及什麼時候建立這些方面提供了很大的靈活性。

一般設計模式從工廠方法開始，當設計者發現須要更大的靈活性時，設計便會向其餘建立型模式演化。

結構型模式

適配器模式：將一個類的接口轉換成客戶但願的另一個接口。使得本來因爲接口不兼容而不能在一塊兒工做的類能夠在一塊兒工做。

橋接模式：將抽象部分與它的實現部分分離，使它們均可以獨立地變化。經過對象組合的關係，解耦不一樣方向的變化。

組合模式：將對象組合成樹形結構以表示「部分-總體」的層次結構，組合模式使得用戶對單個對象和組合對象的使用具備一致性。

裝飾器模式：動態地給一個對象添加一些額外的職責。

外觀模式：爲子系統中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

享元模式：運用共享技術有效的支持大量細粒度的對象。

代理模式：爲其餘對象提供一個代理以控制對這個對象的訪問。

行爲型模式

觀察者模式：定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象都將獲得通知並被自動更新。

模板方法模式：定義一個操做的算法骨架，將一些步驟延遲到子類中，使得子類在不改變一個算法的結構便可重定義該算法的某些特定步驟。

命令模式：將一個請求封裝爲一個對象，從而可使用不一樣的請求對客戶進行參數化，能夠對請求排隊或請求記錄日誌，以及支持可撤銷的操做。

狀態模式：容許一個對象在其內部狀態改變時改變它的行爲，讓對象看起來彷佛修改了它的類。

責任鏈模式：使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有一個對象處理它爲止。

解釋器模式：給定一個語言，定義它的文法的一種表示，並定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。

中介者模式：用一箇中介對象來封裝一系列的對象交互。中介者使各對象不須要顯示地相互引用，從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互。

訪問者模式：表示一個做用於某對象結構中的各元素的操做。使得能夠在不改變各元素類的前提下定義做用於這些元素的新操做。

策略模式：定義一系列的算法，把它們一個個封裝起來，而且使它們能夠相互替換。

備忘錄模式：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態。這樣之後就能夠將該對象恢復到原先保存的狀態。

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

幾個原則

單一職責(SRP)：就一個類而言，應該僅有一個引發它變化的緣由。

開放-封閉原則：軟件實體（類，模塊，函數等等）應該能夠擴展，但不能夠修改。

依賴倒轉原則：高層模塊不該該依賴低層模塊。兩個都應該依賴抽象。抽象不該該依賴細節。細節應該依賴抽象。

里氏代換原則（LSP）：子類型必須可以替換掉它們的父類型。（在軟件裏面，把父類都替換成它的子類，程序的行爲沒有變化。只有當子類能夠替換掉父類，軟件單位的功能不受到影響時，父類才能被真正複用，而子類也可以在父類的基礎上增長新的行爲。）

迪米特法則（LoD）：也叫最少知識原則。若是兩個類沒必要彼此直接通訊，那麼這兩個類就不該該發生直接的相互做用。若是其中一個類須要調用另外一個類的某一個方法的話，能夠經過第三者轉發這個調用。（根本思想是強調了類之間的鬆耦合。在類的結構設計上，每個類都儘可能下降成員的訪問權限，不須要讓別的類知道的字段或行爲就不要公開。）