Kotlin——進階篇(一):設計模式概述

趁着9102年的雙12來臨之際,終於下定決定買了一款椅子,本想着買一款老闆椅的,可是看看本身的一個打工仔(程序猿)身份仍是買了一款便宜的遊戲電競椅。終於能夠把我用25塊錢買的辣雞膠凳子扔了。特此申明:我買電競椅是用來打遊戲的,不是寫代碼的,不過用來寫文章也不過度吧git

當組裝好椅子並坐上去的那一刻,我彷彿找到了一年前寫文章的那個狀態。故而在此係列停更的一年半的狀況下,繼續撿起來寫完它。否則該死的羣友又會說:github

羣友1: J佬,你的教程太監了...
羣友2: 基佬,你的教程太監了...
...
迷之複製ing...
...
我:
複製代碼

我:誰愛寫誰寫,我tm不寫!
複製代碼

好了,不扯了,我但願在2020我被消滅以前,我還在繼續寫...算法

目錄

1、設計模式的六大原則

1.一、開-閉原則(Open-Close Principle

定義編程

所謂開-閉原則,即指一個軟件實體應當對擴展開放,對修改關閉設計模式

即:給出一個貨多個抽象類或接口,規定全部的具體類必須提供方法和屬性,做爲一個抽象層,這個抽象層儘量的知足全部可能性。故而當咱們須要擴展的時候,這個抽象層就沒必要修改,即對應上面的對修改關閉。同時從抽象類或者接口導出一個具體的實現類來改變系統的行爲,即對應上面的對擴展開放bash

做用函數

是爲了使程序的擴展性好,易於維護和升級ui

優勢spa

  • 經過擴展已有的軟件系統,能夠提供新的行爲,來知足軟件的新需求,使得變化中的軟件系統有必定的適應性和靈活性
  • 已有的軟件模塊,特別使抽象層模塊不能在修改,使得變化中的軟件系統有必定的延續性和穩定性

1.二、里氏代換原則(Liskov Substitution Principle

定義設計

所謂里氏代換原則原則,即指的是任何基類出現的地方,其子類必定能出現,反之則不成立。它是對開-閉原則的補充

做用

是對實現抽象化的具體步驟的規範。由於,實現開閉原則的關鍵步驟就是抽象化,而基類與子類的繼承關係就是抽象化的具體實現。

1.三、依賴倒轉原則(Dependence Inversion Principle

定義

  • 要針對接口編程,不要針對實現編程
  • 要依賴與抽象,不要依賴與具體

做用

強調一個系統內實體關係之間的靈活性。由於它是開-閉原則的基礎

1.四、接口隔離原則(Interface Segregation Principle

定義

所謂接口隔離原則,即指使用多個專門的接口比使用一個總接口要好。換言之,一個類對另外一個類的依賴應當是創建在最小接口上的

做用

下降類與類之間的耦合度,下降依賴

例子

一我的天天須要吃早餐、吃午餐、吃晚飯,睡午覺、可能睡個回籠覺、正常睡覺。這裏就把吃飯做爲一個接口,把睡覺做爲一個接口,裏面去分別實現具體的方法。

interface Sleep{
        
        fun sleepMorning()
        
        fun sleepNoon()
        
        fun sleepNight()
        
    }
    
    interface Eat{
        
        fun eatMorning()
        
        fun eatNoon()
        
        fun eatNight()
        
    }
    
複製代碼

1.五、迪米特法則(Demeter Principle

定義

  • 迪米特法又唄稱爲最少知識原則,即一個對象應當對其餘對象儘量少得了瞭解。換言之,一個實體應當儘可能少地與其餘實體之間發生相互做用

做用

使得系統功能模塊相對獨立

1.六、合成複用原則(Composite Reuse Principle

定義

所謂合成複用原則,即指儘可能使用合成/聚合的方式,而不是使用繼承。

做用

在一個新的對象中使用一些已有的對象,使之稱爲新對象的一部分,新的對象經過向這些對象委派從而達到複用已有功能的目的。

2、設計模式簡介

所謂設計模式(Design patterns)表明了一中軟件設計的最佳實踐,一般被有經驗的面向對象的軟件開發人員所採用。設計模式是軟件開發人員在軟件開發過程當中面臨的通常問題的解決方案。這些解決方案是衆多軟件開發人員通過至關長的一段時間的試驗和錯誤總結出來的。

2.一、設計模式的由來

在面向對象的編程中使用模式化方法研究的開創性著做是 Design Patterns - Elements of Reusable Object-Oriented Software,中文譯名是:《設計模式 - 可複用的面向對象軟件元素》,該書首次提到了軟件開發中設計模式的概念。該書的做者共四位,合稱Gang of FourGoF

2.二、設計模式介紹

設計模式是一套被反覆使用的、多數人知曉的、通過分類編目的、代碼設計經驗的總結。

設計模式於己於他人於系統都是多贏的,設計模式使代碼編制真正工程化,設計模式是軟件工程的基石,如同大廈的一塊塊磚石同樣。項目中合理地運用設計模式能夠完美地解決不少問題,每種模式在現實中都有相應的原理來與之對應,每種模式都描述了一個在咱們周圍不斷重複發生的問題,以及該問題的核心解決方案,這也是設計模式能被普遍應用的緣由。

2.三、設計模式的做用

  1. 提高軟件系統的可維護性。但願咱們設計的是可擴展的,具備靈活性以及可插入性的系統。
  2. 提高代碼的可複用性。讓代碼更容易被他人理解、保證代碼可靠。

3、設計模式分類與詳解

設計模式分爲三類,分別是建立型模式結構型模式行爲型模式

3.一、建立型

建立型模式是對類的實例化過程的抽象化,即提供了一種在建立對象的同時隱藏建立邏輯的方式,而不是使用new運算符直接實例化對象。這使得程序在判斷針對某個給定實例須要建立哪些對象時更加靈活。

建立型模式包括:

  • 工廠方法模式(Factory Method Pattern

    它是類的建立模式,它定義一個建立產品對象的接口,將實際的建立工做交給其子類。其中,工廠方法模式又被稱爲虛擬構造子模式或多態性工廠模式

  • 抽象工廠模式(Abstract Factory Pattern

    是全部形態的工廠模式中最爲抽象和最具通常性的一種形態。它的目的是向客戶端提供一個接口,使客戶端在沒必要指定具體產品的狀況下,建立多個產品族中的產品對象。

  • 單例模式(Singleton Pattern

    確保一個類只有一個實例,並且是自行實例化並向整個系統提供這個實例。單例模式通常有7種實現方式,在後續的章節中會一一實現。

  • 建造者模式(Builder Pattern

    能夠將一個產品的內部表象與產品的生產過程分割開來,從而能夠是一個建造過程生成具備不用的內部表象的產品對象。

  • 原型模式(Prototype Pattern

    經過給出一個原型對象來指明說要建立的對象的類型,而後用複製這個原型對象的方法建立出更多同類型的對象。

3.二、結構型

結構型模式是關注類和對象的組合。用來組合接口和定義組合對象得到新功能的方式。

結構型模式包括:

  • 適配器模式(Adapter Pattern

    把一個類的接口變換成客戶端所期待的另外一種接口,從而使本來因接口不匹配而沒法工做的兩個類可以一塊兒正常工做。它分爲類的適配器模式對象的適配器模式

  • 橋接模式(Bridge Pattern

    目的是將抽象化與實現化脫藕,使兩者能夠獨立的變化。

  • 組合模式(Composite Pattern

    1. 又叫部分總體模式,是用於把一組類似的對象看成一個單一的對象。
    2. 依據樹形結構來組合對象,用來表示部分以及總體層次。
    3. 式建立了一個包含本身對象組的類。該類提供了修改相同對象組的方式。
  • 裝飾器模式(Decorator Pattern

    以客戶端透明的方式擴展對象的功能,是繼承關係的一種替代方案。其中,裝飾模式又被稱爲包裝模式。

  • 外觀模式(Facade Pattern

    是隱藏系統的複雜性,並向客戶端提供了一個客戶端能夠訪問系統的接口。它涉及到一個單一的類,該類提供了客戶端請求的簡化方法和對現有系統類方法的委託調用。

  • 享元模式(Flyweight Pattern

    是對象的結構模式,目的是以共享的方式高效地支持大量的細粒度對象,它可以作到共享的關鍵是區份內蘊狀態與外蘊狀態。更詳細說明會在後續的章節出說明。

  • 代理模式(Proxy Pattern

    是對象的結構模式,目的是爲一個對象提供一個代理對象,並由代理對象控制原始對象的引用。其中,代理模式分爲靜態代理動態代理兩種模式。

3.三、行爲型

這些設計模式特別關注對象之間的通訊。

行爲型模式包括:

  • 責任鏈模式(Chain of Responsibility Pattern

    1. 爲請求建立了一個接收者對象的鏈。這種模式給予請求的類型,對請求的發送者和接收者進行解耦
    2. 它一般每一個接收者都包含對另外一個接收者的引用。若是一個對象不能處理該請求,那麼它會把相同的請求傳給下一個接收者,依此類推。
  • 命令模式(Command Pattern

    1. 是一種數據驅動的設計模式
    2. 請求以命令的形式包裹在對象中,並傳給調用對象。調用對象尋找能夠處理該命令的合適的對象,並把該命令傳給相應的對象,該對象執行命令。
  • 解釋器模式(Interpreter Pattern

    提供了評估語言的語法或表達式的方式,它屬於行爲型模式。這種模式實現了一個表達式接口,該接口解釋一個特定的上下文

  • 迭代器模式(Iterator Pattern

    1. 它又被稱爲遊標模式
    2. 它是對象的行爲模式,目的是能夠順序地訪問一個彙集中的元素而沒必要暴露彙集的內部表象。
  • 中介者模式(Mediator Pattern

    下降多個對象和類之間的通訊複雜性。提供了一箇中介類,該類一般處理不一樣類之間的通訊,並支持鬆耦合,使代碼易於維護

  • 備忘錄模式(Memento Pattern

    保存一個對象的某個狀態,以便在適當的時候恢復對象

  • 觀察者模式(Observer Pattern

    1. 它又被稱爲發佈-訂閱模式模型-視圖模式源-監聽器模式從屬者模式
    2. 它定義了一種一對多的依賴關係,讓多個觀察者同時監聽一個主題對象(被觀察者),當這個主題對象發生變化時,會通知全部觀察者對象,讓他們可以自動更新本身
  • 狀態模式(State Pattern

    容許對象在內部狀態發生改變時改變它的行爲,對象看起來好像修改了它的類。

  • 策略模式(Strategy Pattern

    是針對一組算法,將每個算法封裝到具備公共接口的獨立的類中。從而可使得他們能夠相互的替換。

  • 模板模式(Template Pattern

    把一系列含有公共邏輯的類抽象成一個抽象類,將這部分公共邏輯具體方法以及具體構造子的形式實現。而後聲明一系列抽象函數來迫使其子類實現剩餘的邏輯。不一樣的子類能夠以不一樣的方式實現這些抽象方法。其實提及來很複雜,可是就是咱們寫代碼常常會用到的基類。好比說BaseActivityBaseFragment等...

  • 訪問者模式(Visitor Pattern

    使用了一個訪問者類,它改變了元素類的執行算法。經過這種方式,元素的執行算法能夠隨着訪問者改變而改變。根據模式,元素對象已接受訪問者對象,這樣訪問者對象就能夠處理元素對象上的操做。

總結

上面的知識幾乎全是書面性文字,是對設計模式一個總的概述,關於設計模式的介紹、做用等你們瞭解便可。不過設計模式的六大原則是必定要掌握的,畢竟設計模式幾乎都遵循上面的原則。掌握設計模式的分類。後續會爲你們一一詳解每一種設計模式的用法和場景。

若是各位大佬看了以後感受還闊以,就請各位大佬隨便star一下,您的關注是我最大的動力。
個人我的博客Jetictors
個人githubJetictors

歡迎各位大佬進羣共同研究、探索

QQ羣號:497071402

相關文章
相關標籤/搜索