面向對象的7大原則與23種設計模式

時間 2019-12-17

原文原文鏈接

7大原則

單一職責原則（Single Responsibility Principle SRP）

如何劃分一個類、一個函數的職責，每一個人都有本身的見解，這須要根據我的經驗、具體的業務邏輯而定。可是，它也有一些基本的指導原則，例如，兩個徹底不同的功能就不該該放在一個類中。一個類中應該是一組相關性很高的函數、數據的封裝。工程師能夠不斷地審視本身的代碼，根據具體的業務、功能對類進行相應的拆分，這是程序員優化代碼邁出的第一步。
開閉原則（Open Closed Principle OCP)

軟件中的對象（類、模塊、函數等）應該對於擴展是開放的，可是，對於修改是封閉的。
里氏替換原則（Liskov Substitution Principle LSP）

全部引用基類的地方必須能透明地使用其子類的對象。通俗點講，只要父類能出現的地方子類就能夠出現，並且替換爲子類也不會產生任何錯誤或異常，使用者可能根本就不須要知道是父類仍是子類。

里氏替換原則的關鍵就是創建抽象，經過抽象創建規範，具體的實如今運行時替換掉抽象，保證系統的擴展性、靈活性。開閉原則和里氏替換原則每每是生死相依、不棄不離的，經過里氏替換來達到對擴展開放，對修改關閉的效果。然而，這兩個原則都同時強調了一個OOP的重要特性抽象，所以，在開發過程當中運用抽象是走向代碼優化的重要一步。

好比ViewGroup中的addView(View view)，這個view能夠是View的各類子類，也能夠是自定義View。
依賴倒置原則（Dependence Inversion Principle DIP）

模塊間的依賴經過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是經過接口或抽象類產生的。
接口隔離原則（Interface Segregation Principle ISP）

客戶端不該該依賴它不須要的接口。另外一種定義是：類間的依賴關係應該創建在最小的接口上。
迪米特原則（Law of Demeter LOD），又叫最少知識原則（Least Knowledge Principle LKP）

一個對象應該對其餘對象有最少的瞭解。通俗地講，一個類應該對本身須要耦合或調用的類知道得最少，類的內部如何實現與調用者或者依賴者不要緊，調用者或者依賴者只須要知道它須要的方法便可，其餘的可一律不用管。類與類之間的關係越密切，耦合度越大，當一個類發生改變時，對另外一個類的影響也越大。
組合/聚合複用原則（Composition/Aggregation Principle CARP）

在面向對象的設計中，若是直接繼承基類，會破壞封裝，由於繼承將基類的實現細節暴露給子類；若是基類的實現發生改變，則子類的實現也不得不發生改變；從基類繼承而來的實現是靜態的，不可能在運行時發生改變，沒有足夠的靈活性。因而就提出了組合/聚合複用原則，也就是在實際開發設計中，儘可能使用合成/聚合，不要使用類繼承。即在一個新的對象裏面使用一些已有的對象，使之成爲新對象的一部分，新對象經過向這些對象的委派達到複用已有功能的目的。就是說要儘可能的使用合成和聚合，而不是繼承關係達到複用的目的。

23種設計模式

單例模式
①靜態常量（靜態常量或者靜態代碼塊）
②雙重檢查同步代碼塊
③靜態內部類
④枚舉
⑤AtomicRerence
Builder模式
一般做爲配置類的構建器將配置的構建和表示分離開來，同時也是將配置從目標類中隔離出來，避免過多的setter方法。Builder模式比較常見的實現形式是經過調用鏈實現，這樣使得代碼更簡介、易懂。

public class Config {
    int config1;
    int config2;
    private Config () {
    }
    public static class Buider {
        int config1;
        int config2;
        public Buider setConfig1(int config1){
            this.config1 = config1;
            return this;
        }
        public Buider setConfig2(int config2){
            this.config2 = config2;
            return this;
        }
        private void apply(Config config){
            config.config1 = this.config1;
            config.config2 = this.config2;
        }
        public Config create(){
            Config config = new config();
            this.apply(config);
            return config;
        }
    }

複製代碼

原型模式
原型模式本質上就是對象拷貝，容易出現的問題是深拷貝、淺拷貝。使用原型模式能夠解決構建複雜對象的資源消耗問題，可以在某些場景下提高建立對象的效率。還有一個重要的用途就是保護性拷貝，也就是某個對象對外多是隻讀的，爲了防止外部對這個只讀對象修改，一般能夠經過返回一個對象拷貝的形式實現只讀的限制。程序員
工廠方法模式算法
抽象工廠模式
在任何須要生成複雜對象的地方，均可以使用工廠方法模式。複雜對象適合使用工廠模式，用 new就能夠完成建立的對象無需使用工廠模式。方便建立同種產品類型的複雜參數對象。設計模式
策略模式
若是將這些算法或者策略抽象出來，提供一個統一的接口，不一樣的算法或者策略有不一樣的實現類，這樣在程序客戶端就能夠經過注入不一樣的實現對象來實現算法或者策略的動態替換，這種模式的可擴展性、可維護性也就更高。策略模式主要用來分離算法，在相同的行爲抽象下有不一樣的具體實現策略。這個模式很好地演示了開閉原則，也就是定義抽象，注入不一樣的實現，從而達到很好的可擴展性。緩存
狀態模式
狀態模式中的行爲是由狀態來決定的，不一樣的狀態下有不一樣的行爲。狀態模式和策略模式的結構幾乎徹底同樣，但它們的目的、本質卻徹底不同。狀態模式的行爲是平行的、不可替換的，策略模式的行爲是彼此獨立、可相互替換的。用一句話來表述，狀態模式把對象的行爲包裝在不一樣的狀態對象裏，每個狀態對象都有一個共同的抽象狀態基類。狀態模式的意圖是讓一個對象在其內部狀態改變的時候，其行爲也隨之改變。bash
責任鏈模式
使多個對象都有機會處理請求，從而避免了請求的發送者和接收者之間的耦合關係。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，直到有對象處理它爲止。數據結構
解釋器模式
給定一個語言，定義它的文法的一種表示，並定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。app
命令行模式
將調用者與行爲實現者解耦框架
觀察者模式
定義對象間一種一對多的依賴關係，使得每當一個對象改變狀態，則全部依賴千它的對象都會獲得通知並被自動更新。ide
備忘錄模式
在不破壞封閉的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態，這樣，之後就能夠將該對象恢復到原先保存的狀態。函數
迭代器模式
提供一種方法順序訪問一個容器對象中的各個元素，而又不須要暴露該對象的內部表示。
模板方法模式
定義一個操做中的算法的框架，而將一些步驟延遲到子類中，使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。使用場景：
(1)多個子類有公有的方法，而且邏輯基本相同時。
(2)重要、複雜的算法，能夠把核心算法設計爲模板方法週一邊的相關細節功能則由各個子類實現。
(3)重構時，模板方法模式是一個常用的模式，把相同的代碼抽取到父類中，而後經過鉤子函數約束其行爲。
訪問者模式
定義及使用場景
定義：
封裝一些做用於某種數據結構中的各元素的操做，它能夠在不改變這個數據結構的前提下定義做用於這些元素的新的操做。
能夠對定義這麼理解：有這麼一個操做，它是做用於一些元素之上的，而這些元素屬於某一個對象結構。同時這個操做是在不改變各元素類的前提下，在這個前提下定義新操做是訪問者模式精髓中的精髓。

使用場景：
（1）對象結構比較穩定，但常常須要在此對象結構上定義新的操做。
（2）須要對一個對象結構中的對象進行不少不一樣的且不相關的操做，而須要避免這些操做「污染」這些對象的類，也不但願在增長新操做時修改這些類。
中介者模式

定義：中介者模式包裝了一系列對象相互做用的方式，使得這些對象沒必要相互明顯做用。從而使它們能夠鬆散耦合。當某些對象之間的做用發生改變時，不會當即影響其餘的一些對象之間的做用。保證這些做用能夠彼此獨立的變化。

使用場景：當對象之間的交互操做不少且每一個對象的行爲操做都依賴彼此時，爲防止在修改一個對象的行爲時，同時涉及不少其餘對象的行爲，可以使用中介者模式。

代理模式
靜態代理，動態代理。
組合模式
View和ViewGroup，Folder和File
適配器模式
類適配器、對象適配器。Recyclerview的adapter是將數據轉成items。
裝飾者模式
動態地給一個對象添加一些額外的職責。與代理模式的區別：

裝飾模式，突出的是運行期增長行爲，這和繼承是不一樣的，繼承是在編譯期增長行爲。
代理模式，控制對象的訪問。

享元模式
好比鏈接池、線程池等各類緩存池，複用減小內存、建立開銷和gc。
外觀模式
向外提供SDK時的封裝。子模塊的封裝。向外提供一個統一高層次的接口，屏蔽實現細節。
橋接模式將抽象部分與實現部分分離，使它們均可以獨立地進行變化。橋接模式將繼承關係轉化成關聯關係，它下降了類與類之間的耦合度，減小了系統中類的數量，也減小了代碼量。