小提示：

不要以為用了面向?qū)ο笳Z言寫出的就是面向?qū)ο蟠a，如果沒有利用其特性那可能還是面向過程，比如沒有利用權(quán)限修飾符、一個(gè)類一把梭等等....

2. 六大設(shè)計(jì)原則才是一切設(shè)計(jì)的基石

設(shè)計(jì)原則是基于面向?qū)ο笏枷胙茏兂鰜淼囊恍┮?guī)則，用來解決實(shí)際開發(fā)中的一些痛點(diǎn)，是所有設(shè)計(jì)的底層思想，也是我個(gè)人認(rèn)為是設(shè)計(jì)/架構(gòu)領(lǐng)域最重要的知識(shí)，所以請(qǐng)大家務(wù)必掌握好

2.1 單一設(shè)計(jì)原則

單一原則很好理解，指一個(gè)函數(shù)或者一個(gè)類再或者一個(gè)模塊，職責(zé)越單一復(fù)用性就越強(qiáng)，同時(shí)能夠間接降低耦合性。

案例：本地獲取用戶信息，提交到網(wǎng)絡(luò)

fun post(){
        //創(chuàng)建數(shù)據(jù)庫訪問對(duì)象Dao
        val userDao = ...(這一過程很復(fù)雜)
        
        //從本地獲取
        val age = dao.getAge()
        val name = dao.getName()
        //....省略大量字段

        //將個(gè)人信息提交至網(wǎng)絡(luò)
        http.request(age,name,....)
}

以上案例將創(chuàng)建、獲取、提交三步操作寫到同一個(gè)函數(shù)中，很顯然違背了單一設(shè)計(jì)原則，面臨的問題也很明顯，當(dāng)修改創(chuàng)建、獲取、提交任一過程時(shí)都會(huì)影響到其他二者，千萬不要說"我注意一點(diǎn)就不會(huì)出錯(cuò)"這種話，因?yàn)槿瞬皇菣C(jī)器改動(dòng)就可能出錯(cuò)，此時(shí)可以通過單一設(shè)計(jì)原則做一次重構(gòu)，代碼如下：

fun getUserDao():UserDao{
        ...
        return dao
}
    
fun getUserInfo():UserInfo{
        val dao = getUserDao()
        val userInfo = UserInfo()
        userInfo.age = dao.getAge()
        userInfo.name = dao.getName()
        ...
        return userInfo
}
    
fun post(){
        val userInfo = getUserInfo()
        //將個(gè)人信息提交至網(wǎng)絡(luò)
        http.request(userInfo.age,userInfo.name,....)
}

三步操作被拆至三個(gè)函數(shù) 互不影響，從根本上杜絕因改動(dòng)帶來的一系列問題。所以使用面向?qū)ο笳Z言開發(fā)時(shí)，不要急著寫代碼，要優(yōu)先考慮下模塊、類、函數(shù)...的設(shè)計(jì)是否足夠單一

2.2 開閉原則

一句話概括開閉原則:對(duì)擴(kuò)展開放，修改關(guān)閉。它即充分詮釋抽象、多肽特性，又是多數(shù)行為型設(shè)計(jì)模式的基礎(chǔ)，遍布于各大優(yōu)秀框架之中，是最重要的一條設(shè)計(jì)原則，僅這一條原則就能把你的設(shè)計(jì)能力提高40%

舉個(gè)例子讓大家感受一下：

需求：通過SQLite做CRUD操作

class SQLiteDao{
    public void insert() {
         //通過SQLite做insert
    }
    public void delete() {
        //通過SQLite做insert
    }
}

SQLiteDao dao = new SQLiteDao();
dao.insert();
...

以上是最簡單粗暴的寫法，但存在一個(gè)致命問題，如果某一天想替換SQLite業(yè)務(wù)層基本要?jiǎng)右槐?，改?dòng)就存在出錯(cuò)的可能，并且需要做大量的重復(fù)操作

面對(duì)以上問題可以利用抽象、多肽特性基于開閉原則做出重構(gòu)，代碼如下：

interface IDao{
    void insert();
    void delete();
}

class SQLiteDao implements IDao{
    @Override
    public void insert() {
         //通過SQLite做insert
    }
    @Override
    public void delete() {
        //通過SQLite做insert
    }
}

class RoomDao implements IDao{
    @Override
    public void insert() {
        //通過Room做insert
    }
    @Override
    public void delete() {
        //通過Room做delete
    }
}

//擴(kuò)展點(diǎn)
IDao dao = new SQLiteDao();
dao.insert();

• 定義功能接口IDao
• 定義類SQLiteDao、RoomDao并實(shí)現(xiàn)IDao的功能
• 業(yè)務(wù)層基于接口IDao進(jìn)行編程

重構(gòu)后，當(dāng)需要將SQLite替換至Room時(shí)，只需將注釋擴(kuò)展點(diǎn)處SQLiteDao替換成RoomDao即可，其他地方完全不用改動(dòng)。這就是所謂的擴(kuò)展開放，修改關(guān)閉

在業(yè)務(wù)不斷迭代情況下，唯一不變的就是改變，這種背景下我們能做的只有在代碼中基于開閉原則多留擴(kuò)展點(diǎn)以不變應(yīng)萬變。

2.3 迪米特法則

基本概念：不該有直接依賴關(guān)系的模塊不要有依賴。有依賴關(guān)系的模塊之間，盡量只依賴必要的接口。

迪米特法則很好理解并且非常實(shí)用，違背迪米特法則會(huì)產(chǎn)生什么問題？還以2.1面向過程代碼舉例：

class Wallet{
    /**
     * 余額
     */
    int balance;

    /**
     * 存錢
     */
    void saveMoney(int money){
        balance += money;
    }

    /**
     * 花錢
     */
    void spendMoney(int money){
        balance -= money;
    }
}

Wallet的設(shè)計(jì)違背了迪米特法則，畢竟外部只需要save和spend功能，將balance暴漏使用者就有權(quán)限直接修改其值，可能會(huì)對(duì)整個(gè)Wallet功能造成影響。此時(shí)應(yīng)基于迪米特法則對(duì)Wallet進(jìn)行改造，將balance通過封裝特性增加private修飾符

迪米特法則和單一設(shè)計(jì)原則很像，前者符合松耦合后者符合高內(nèi)聚

2.4 接口隔離原則

基本概念：接口的調(diào)用者不應(yīng)該依賴它不需要的接口。

乍一看與迪米特法則很相似。先來看下什么樣的接口違背接口隔離原則：

interface Callback{
    /**
     * 點(diǎn)擊事件回調(diào)方法
     */
    void clickCallback();
    /**
     * 滾動(dòng)事件回調(diào)方法
     */
    void scrollCallback();
}

接口Callback包含點(diǎn)擊、滾動(dòng)兩個(gè)回調(diào)方法，面臨的問題有兩個(gè)：

• 某些特定場景使用者只需要依賴點(diǎn)擊回調(diào)，那滾動(dòng)回調(diào)便成了多余，把外部不需要的功能暴露出來就存在誤操作的可能。
• 點(diǎn)擊和滾動(dòng)本來就是兩種特性，強(qiáng)行揉到一塊只能讓接口更臃腫，進(jìn)而降低其復(fù)用性

根據(jù)接口隔離原則改造后如下：

interface ClickCallback{
    /**
     * 點(diǎn)擊事件回調(diào)方法
     */
    void clickCallback();
}

interface ScrollCallback{
    /**
     * 滾動(dòng)事件回調(diào)方法
     */
    void scrollCallback();
}

基于單一設(shè)計(jì)原則把點(diǎn)擊和滾動(dòng)拆分成兩個(gè)接口，將模塊間隔離的更徹底。并且由于粒度更細(xì)，所以復(fù)用性也更高

接口隔離原則與迪米特法則目的很相似，都可以降低模塊間依賴關(guān)系。但接口隔離更側(cè)重于設(shè)計(jì)單一接口，提升復(fù)用性并間接降低模塊間依賴關(guān)系，而迪米特法則是直接降低模塊間依賴關(guān)

2.5 里氏替換原則

基本概念：

設(shè)計(jì)子類的時(shí)候，要遵守父類的行為約定。父類定義了函數(shù)的行為約定，子類可以改變函數(shù)的內(nèi)部實(shí)現(xiàn)邏輯，但不能改變函數(shù)原有的行為約定。

里氏替換非常簡單并且很容易遵守，在使用繼承時(shí)，允許復(fù)寫父類方法，但不要改變其功能。比如自定義View，子類的onMeasure中一定要調(diào)用setMeasureaDimission()方法（或者直接使用super），否則會(huì)影響父類方法功能（會(huì)拋異常），也既違背了里氏替換原則。

2.6 依賴倒置原則

2.1章節(jié)查看

什么是依賴倒置？

高層模塊(使用者)不應(yīng)依賴低層模塊(被使用者)，它們共同依賴同一個(gè)抽象，抽象不要依賴具體實(shí)現(xiàn)細(xì)節(jié)，具體實(shí)現(xiàn)細(xì)節(jié)依賴抽象。

其實(shí)核心點(diǎn)就是基于接口而非實(shí)現(xiàn)編程，2.2數(shù)據(jù)庫案例也符合依賴倒置原則，高層模塊(業(yè)務(wù)層)不依賴于低層模塊(SQLiteDao/RoomDao),而是依賴于抽象(IDao),可見依賴倒置也是開閉原則擴(kuò)展而來。
區(qū)別是依賴倒置更側(cè)重于指導(dǎo)框架的設(shè)計(jì)，框架層應(yīng)該盡量將更多的細(xì)節(jié)隱藏在內(nèi)部，對(duì)外只暴露抽象(抽象類/接口)，指導(dǎo)框架設(shè)計(jì)這方面核心就是控制反轉(zhuǎn)

3. 設(shè)計(jì)模式只是設(shè)計(jì)原則的產(chǎn)物而已

設(shè)計(jì)模式共有23種，詳細(xì)描述都能出一本書出來。本小結(jié)僅會(huì)分享一些通用的思路，個(gè)人認(rèn)為還是比較硬核的，畢竟設(shè)計(jì)主要還是思想，而非生搬硬套

3.1 設(shè)計(jì)模式該怎么去學(xué)？

本小節(jié)會(huì)分析幾個(gè)常見的設(shè)計(jì)模式核心思想以及設(shè)計(jì)背景，用于拋磚引玉

工廠模式

基本概念：用于創(chuàng)建復(fù)雜對(duì)象

創(chuàng)建復(fù)雜對(duì)象常規(guī)寫法如下：

class B{
    ...
}

class D{
    void test(){
        B b = ....(創(chuàng)建B的過程很復(fù)雜)
        ...
    }
}

在使用的地方直接創(chuàng)建，如果直接new倒也沒啥問題，但如果創(chuàng)建過程過于復(fù)雜，當(dāng)修改創(chuàng)建過程時(shí)就會(huì)影響到test()，進(jìn)而存在一些未知的隱患。

這一問題可通過迪米特法則進(jìn)行改造：

class FactoryB{
    ...
    static B createB(){
        .....(B創(chuàng)建過程)
        return b;
    }
}
class D{
    void test1(){
        B b = FactoryB.create();
        ...
    }
}

B的創(chuàng)建本身就于調(diào)用者無關(guān)，將創(chuàng)建過程轉(zhuǎn)移到類FactoryB中，根本上避免了創(chuàng)建過程對(duì)調(diào)用者的影響。改造后就是一個(gè)標(biāo)準(zhǔn)的簡單工廠模式，所以簡單工廠模式的核心思想就是迪米特法則

觀察者模式

基本概念：當(dāng)一個(gè)對(duì)象發(fā)生改變時(shí)需要通知到另一個(gè)對(duì)象

粗暴寫法：

/**
 * 觀察者
 */
class Observer{
    /**
     * 接收通知
     */
    void receive(){
        //具體邏輯
    }
}

/**
 * 被觀察者
 */
class Observable{
    /**
     * 發(fā)送通知
     */
    void send(){
        Observer observer = new Observer();
        observer.receive();
    }
}

Observable(被觀察者)內(nèi)部直接持有Observer(觀察者)，在合適的時(shí)機(jī)發(fā)出通知，但這種寫法有兩個(gè)很明顯的問題：

• 擴(kuò)展性差：當(dāng)存在多個(gè)觀察者Observer1,Observer2...時(shí),Observable需要逐個(gè)手動(dòng)創(chuàng)建發(fā)出通知
• 耦合性強(qiáng)：Observable直接持有Observer對(duì)象，而Observer可能暴露出一些Observable不需要的屬性/方法，存在誤操作的風(fēng)險(xiǎn)

面對(duì)以上兩個(gè)問題可以利用開閉原則和接口隔離原則進(jìn)行改造：

interface IObserver{
    /**
     * 接收通知
     */
    void receive();
}

class Observable{
    /**
     * 觀察者集合
     */
    private final List<IObserver> observers = new ArrayList<>();

    /**
     * 發(fā)送通知
     */
    void send(){
        for (IObserver observer : observers){
            observer.receive();
        }
    }
}

以上是一個(gè)標(biāo)準(zhǔn)的觀察者模式。通過接口隔離原則設(shè)計(jì)IObserver接口保證其單一性，避免模塊之間依賴關(guān)系過強(qiáng)造成的安全隱患，解決了耦合性強(qiáng)問題。通過開閉原則維護(hù)一個(gè)observers，當(dāng)新增觀察者時(shí)只需添加到observers即可，符合擴(kuò)展開放、修改關(guān)閉，解決類擴(kuò)展性差問題。

所以開閉原則，接口隔離原則是觀察者模式擴(kuò)展性強(qiáng)，耦合性低的根本原因吶

以上三個(gè)案例足以表明設(shè)計(jì)模式的核心就是設(shè)計(jì)原則吶，所以學(xué)會(huì)設(shè)計(jì)模式的竅門就是先掌握設(shè)計(jì)原則

3.2 "鹽加少許" 只可意會(huì)

據(jù)我所知有一部分小伙伴覺得用設(shè)計(jì)模式很酷，以至于拿著錘子看什么都是釘子，很簡單的代碼還非要用幾個(gè)設(shè)計(jì)模式包裝下。還有另一部分小伙伴對(duì)設(shè)計(jì)模式理解不夠深刻，把握不好應(yīng)用場景，經(jīng)常生搬硬套做出多余的設(shè)計(jì)。以上兩種現(xiàn)象 不但解決不了任何問題反而會(huì)降低代碼的可讀性

究竟什么場景下需要用設(shè)計(jì)模式呢？關(guān)于這個(gè)問題我只能回答合適的場景，因?yàn)樗緵]有一個(gè)固定答案。就如同老師傅做飯時(shí)講的少許鹽、少許油一樣，因?yàn)椴煌氖巢男枰挠望}不一樣，所以不好去量化，只能根據(jù)自己的經(jīng)驗(yàn)去放?；貧w到代碼中也是一樣的，我們?cè)趯?shí)踐中需要不斷思考，嘗試去發(fā)現(xiàn)開發(fā)中的痛點(diǎn)，設(shè)計(jì)模式就是用來解決這些痛點(diǎn)的，所以只有理清背景才能將設(shè)計(jì)模式用的恰到好處

3.3 自創(chuàng)設(shè)計(jì)模式

有一說一23種設(shè)計(jì)模式我也不是全懂，但由于我懂設(shè)計(jì)原則我一樣可以寫出易維護(hù)的代碼，甚至自創(chuàng)設(shè)計(jì)模式