[[409470]]

本文轉(zhuǎn)載自微信公眾號(hào)「微觀技術(shù)」，作者Tom哥。轉(zhuǎn)載本文請(qǐng)聯(lián)系微觀技術(shù)公眾號(hào)。

大家好，我是Tom哥~

面對(duì)復(fù)雜的業(yè)務(wù)場(chǎng)景，千變?nèi)f化的客戶(hù)需求，如何以一變應(yīng)萬(wàn)變，以最小的開(kāi)發(fā)成本快速落地實(shí)現(xiàn)，同時(shí)保證系統(tǒng)有著較低的復(fù)雜度，能夠保證系統(tǒng)后續(xù)de持續(xù)迭代能力，讓系統(tǒng)擁有較高的可擴(kuò)展性。

這些是一個(gè)合格的架構(gòu)師必須修煉的基礎(chǔ)內(nèi)功，但是如何修煉這門(mén)神功???

我將常用的軟件設(shè)計(jì)模式，做了匯總，目錄如下：

(考慮到內(nèi)容篇幅較大，為了便于大家閱讀，將軟件設(shè)計(jì)模式系列(共23個(gè))拆分成四篇文章，每篇文章講解六個(gè)設(shè)計(jì)模式，采用不同的顏色區(qū)分，便于快速消化記憶)

本文是主要講解橋接模式、組合模式、裝飾模式、門(mén)面模式、代理模式、責(zé)任鏈模式

1、橋接模式

自然界一般由實(shí)體和行為組成。當(dāng)然為了提升系統(tǒng)的擴(kuò)展性，它們兩個(gè)又可以各自抽象，然后在抽象類(lèi)中描述兩者的依賴(lài)。

定義：

將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。

什么場(chǎng)景使用橋接模式?

• 一個(gè)類(lèi)存在兩個(gè)(或多個(gè))獨(dú)立變化的維度，且這兩個(gè)(或多個(gè))維度都需要獨(dú)立進(jìn)行擴(kuò)展。
• 對(duì)于那些不希望使用繼承或因?yàn)槎鄬永^承導(dǎo)致系統(tǒng)類(lèi)的個(gè)數(shù)急劇增加的系統(tǒng)，橋接模式尤為適用。

核心思路：

• 抽象實(shí)體：定義的一種抽象分類(lèi)。比如：人
• 具體實(shí)體：繼承抽象實(shí)體的子類(lèi)實(shí)體。比如：中國(guó)人、美國(guó)人、韓國(guó)人
• 抽象行為：定義抽象實(shí)體中具備的多種行為。比如：學(xué)漢語(yǔ)、吃漢堡
• 具體行為：實(shí)現(xiàn)抽象行為的具體算法。比如：中國(guó)人學(xué)漢語(yǔ)、美國(guó)人吃漢堡

代碼示例：

/** 
 * @author 微信公眾號(hào)：微觀技術(shù) 
 * 抽象實(shí)體 
 */ 
public abstract class AbstractEntity { 
    protected AbstractBehavior abstractBehavior; 
 
    public AbstractEntity(AbstractBehavior abstractBehavior) { 
        this.abstractBehavior = abstractBehavior; 
    } 
 
    public abstract void out(); 
 
} 
 
/** 
 * 抽象行為 
 */ 
public interface AbstractBehavior { 
 
    public String action(String name); 
} 
 
/** 
 * 關(guān)于食物的行為 
 */ 
public class FoodBehavior implements AbstractBehavior { 
 
    @Override 
    public String action(String name) { 
        if ("中國(guó)人".equals(name)) { 
            return "吃 餃子"; 
        } else if ("美國(guó)人".equals(name)) { 
            return "吃 漢堡"; 
        } 
        return null; 
    } 
} 

橋接模式是將抽象與抽象之間分離，具體實(shí)現(xiàn)類(lèi)依賴(lài)于抽象。抽象的分離間接完成了具體類(lèi)與具體類(lèi)之間的解耦，它們之間使用抽象來(lái)進(jìn)行組合或聚合，而不再靠多重繼承來(lái)實(shí)現(xiàn)。本質(zhì)是將一個(gè)對(duì)象的實(shí)體和行為分離，然后再基于這兩個(gè)維度進(jìn)行獨(dú)立的演化。

適用場(chǎng)景：

• 拆分復(fù)雜的類(lèi)對(duì)象時(shí)。當(dāng)一個(gè)類(lèi)中包含大量對(duì)象和方法時(shí)，既不方便閱讀，也不方便修改。
• 希望從多個(gè)獨(dú)立維度上擴(kuò)展時(shí)。比如，系統(tǒng)功能性和非功能性角度，業(yè)務(wù)或技術(shù)角度等。
• 運(yùn)行時(shí)，組合不同的組件

2、組合模式

定義：

組合模式也稱(chēng)整體模式，把一組相似的對(duì)象當(dāng)作一個(gè)單一的對(duì)象，然后將對(duì)象組合成樹(shù)形結(jié)構(gòu)以表示整個(gè)層次結(jié)構(gòu)。

這里邊有兩個(gè)關(guān)鍵點(diǎn)：1、樹(shù)形結(jié)構(gòu)分層 2、業(yè)務(wù)統(tǒng)一化來(lái)簡(jiǎn)化操作

核心思路：

• 抽象組件(AbstractNode)：定義需要實(shí)現(xiàn)的統(tǒng)一操作。
• 組合節(jié)點(diǎn)(CompositeNode)：抽象組件的衍生子類(lèi)，包含了若干孩子節(jié)點(diǎn)(其它組合節(jié)點(diǎn)或葉子節(jié)點(diǎn))。
• 葉子節(jié)點(diǎn)(LeafNode)：抽象組件的子類(lèi)，但它的下面沒(méi)有子節(jié)點(diǎn)。

代碼示例：

public abstract class AbstractNode { 
    public abstract void add(AbstractNode abstractNode); 
    public abstract void remove(AbstractNode abstractNode); 
    public abstract void action(); 
} 
 
public class CompositeNode extends AbstractNode { 
    private Long nodeId; 
    private List<AbstractNode> childNodes;  //存放子節(jié)點(diǎn)列表 
    public CompositeNode(Long nodeId, List<AbstractNode> childNodes) { 
        this.nodeId = nodeId; 
        this.childNodes = childNodes; 
    } 
    @Override 
    public void add(AbstractNode abstractNode) { 
        childNodes.add(abstractNode); 
    } 
    @Override 
    public void remove(AbstractNode abstractNode) { 
        childNodes.remove(abstractNode); 
    } 
    @Override 
    public void action() { 
        for (AbstractNode childNode : childNodes) { 
            childNode.action(); 
        } 
    } 
} 
 
public class LeafNode extends AbstractNode { 
    private Long nodeId; 
    public LeafNode(Long nodeId) { 
        this.nodeId = nodeId; 
    } 
    @Override 
    public void add(AbstractNode abstractNode) { 
        // 無(wú)子節(jié)點(diǎn)，無(wú)需處理 
        return; 
    } 
    @Override 
    public void remove(AbstractNode abstractNode) { 
        // 無(wú)子節(jié)點(diǎn)，無(wú)需處理 
        return; 
    } 
    @Override 
    public void action() { 
        System.out.println("葉子節(jié)點(diǎn)編號(hào)：" + nodeId); 
    } 
} 

葉子節(jié)點(diǎn)不能新增、刪除子節(jié)點(diǎn)，所以對(duì)應(yīng)的方法為空。

組合模式本質(zhì)上封裝了復(fù)雜結(jié)構(gòu)的內(nèi)在變化，讓使用者通過(guò)一個(gè)統(tǒng)一的整體來(lái)使用對(duì)象之間的結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)方面支持樹(shù)形結(jié)構(gòu)、環(huán)形結(jié)構(gòu)、網(wǎng)狀結(jié)構(gòu)。如我們常見(jiàn)的 深度優(yōu)先搜索、廣度優(yōu)先搜索都是采用這種模式。

適用場(chǎng)景：

• 一組對(duì)象按照某種層級(jí)結(jié)構(gòu)進(jìn)行管理。如：管理文件夾和文件，管理訂單下的商品。
• 需要按照統(tǒng)一的行為來(lái)處理復(fù)雜結(jié)構(gòu)中的對(duì)象
• 快速擴(kuò)展對(duì)象組合。

手機(jī)開(kāi)始是按品牌來(lái)歸屬分類(lèi)，現(xiàn)在業(yè)務(wù)增加價(jià)格維度分類(lèi)，我們只需要引入新的分支節(jié)點(diǎn)，按新的維度構(gòu)建組合關(guān)系。

3、裝飾模式

定義：

動(dòng)態(tài)地向一個(gè)現(xiàn)有對(duì)象添加新的職責(zé)和行為，同時(shí)又不改變其結(jié)構(gòu)，相當(dāng)于對(duì)現(xiàn)有的對(duì)象進(jìn)行包裝。

核心思路：

• 抽象組件(Component)：裝飾器基類(lèi)，定義組件的基本功能
• 具體組件(ConcreteComponent)：抽象組件的具體實(shí)現(xiàn)
• 抽象裝飾器(Decorator)：包含抽象組件的引用
• 具體裝飾器(ConcreteDecorator)：抽象裝飾器的子類(lèi)，并重寫(xiě)組件接口方法，同時(shí)可以添加附加功能。

代碼示例：

public abstract class Component { 
    public abstract void execute(); 
} 
 
public class ConcreteComponent extends Component { 
    @Override 
    public void execute() { 
        System.out.println("具體子類(lèi) ConcreteComponent invoke !"); 
    } 
} 
 
public class Decorator extends Component { 
    protected Component component; 
    public Decorator(Component component) { 
        this.component = component; 
    } 
    @Override 
    public void execute() { 
        component.execute(); 
    } 
} 
 
public class ConcreteDecorator extends Decorator { 
    public ConcreteDecorator(Component component) { 
        super(component); 
    } 
    @Override 
    public void execute() { 
        System.out.println("裝飾器子類(lèi) ConcreteDecorator invoke !"); 
        super.execute(); 
    } 
} 

裝飾模式本質(zhì)上就是給已有不可修改的類(lèi)附加新的功能，同時(shí)還能很方便地撤銷(xiāo)。

適用場(chǎng)景：

• 無(wú)需修改代碼的情況下即可使用對(duì)象， 且希望在運(yùn)行時(shí)為對(duì)象新增額外的功能
• 將業(yè)務(wù)邏輯組織為層次結(jié)構(gòu)，可以為各層創(chuàng)建一個(gè)裝飾，在運(yùn)行時(shí)將各種不同邏輯組合成對(duì)象。由于這些對(duì)象都遵循通用接口，客戶(hù)端代碼能以相同的方式使用這些對(duì)象。
• 不支持繼承擴(kuò)展類(lèi)的場(chǎng)景。如：final 關(guān)鍵字限制了某個(gè)類(lèi)的進(jìn)一步擴(kuò)展，可以通過(guò)裝飾器對(duì)其進(jìn)行封裝，從而具備擴(kuò)展能力。

4、門(mén)面模式

定義：

• 門(mén)面模式提供一個(gè)高層次的接口，要求一個(gè)子系統(tǒng)的外部與其內(nèi)部的通信必須通過(guò)一個(gè)統(tǒng)一的對(duì)象進(jìn)行，使得子系統(tǒng)更易于使用。
• 門(mén)面模式要求我們使用統(tǒng)一的標(biāo)準(zhǔn)與系統(tǒng)交互，比如：我們打印日志基本會(huì)選擇slf4j框架，其內(nèi)部統(tǒng)一了log4j、log4j2、CommonLog等日志框架，簡(jiǎn)化了我們的開(kāi)發(fā)成本。

核心思路：

門(mén)面系統(tǒng)。接收外部請(qǐng)求，并將請(qǐng)求轉(zhuǎn)發(fā)給適當(dāng)?shù)淖酉到y(tǒng)進(jìn)行處理

子系統(tǒng)。表示某個(gè)領(lǐng)域內(nèi)的功能實(shí)現(xiàn)、或者具體子接口實(shí)現(xiàn)，比如，訂單、支付等，專(zhuān)門(mén)處理由門(mén)面系統(tǒng)指派的任務(wù)。

簡(jiǎn)單來(lái)講，引入一個(gè)外觀角色來(lái)簡(jiǎn)化客戶(hù)端與子系統(tǒng)之間的交互，為復(fù)雜的子系統(tǒng)調(diào)用提供一個(gè)統(tǒng)一的入口。

可能很多人有疑問(wèn)，這個(gè)不就是代理模式嗎?

門(mén)面模式可能代理的是多個(gè)接口，而代理模式通常只是代理一個(gè)接口。

業(yè)務(wù)場(chǎng)景：

移動(dòng)互聯(lián)網(wǎng)，我們都習(xí)慣了在線支付，相信很多人在付款時(shí)都聽(tīng)過(guò)這么一句話，”微信支付還是支付寶“，商戶(hù)根據(jù)用戶(hù)反饋再針對(duì)性選擇收款渠道。

是不是很繁瑣，為了解決這個(gè)問(wèn)題，市面就有了聚合支付(該領(lǐng)域做非常棒的是收錢(qián)吧)，整個(gè)業(yè)務(wù)模式就是這節(jié)要講的門(mén)面模式，不管你用什么軟件支付，只要打開(kāi)付款二維碼即可，收錢(qián)吧底層識(shí)別解析二維碼，并根據(jù)掃描結(jié)果自動(dòng)適配對(duì)應(yīng)的收款渠道，完成用戶(hù)的扣款動(dòng)作，確實(shí)帶來(lái)不錯(cuò)的用戶(hù)體驗(yàn)。

優(yōu)點(diǎn)：

• 簡(jiǎn)化復(fù)雜系統(tǒng)，提供統(tǒng)一接口規(guī)范。比如：JPA提供了統(tǒng)一Java持久層API，底層適配多樣化的存儲(chǔ)系統(tǒng)。
• 復(fù)雜的業(yè)務(wù)邏輯由內(nèi)部子系統(tǒng)消化，只要對(duì)外接口規(guī)范不變，外部調(diào)用方不需要頻繁修改
• 擴(kuò)展性較好，類(lèi)似于SPI架構(gòu)一樣，支持水平擴(kuò)展。
• 較高的平滑過(guò)渡性。比如：我們要對(duì)老的系統(tǒng)架構(gòu)升級(jí)，開(kāi)發(fā)一系列新接口來(lái)替換原來(lái)的老接口，過(guò)渡期需要新老灰度測(cè)試、流量切換、平滑升級(jí)，可以采用該模式。門(mén)面模式在兼容多套系統(tǒng)、系統(tǒng)重構(gòu)方面是把利器。

5、代理模式

定義：

為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問(wèn)

現(xiàn)實(shí)場(chǎng)景：

• 房產(chǎn)中介
• 包工頭

核心思路：

• 抽象主題類(lèi)(AbstractSubject)：定義接口方法，供客戶(hù)端使用
• 主題實(shí)現(xiàn)類(lèi)(RealSubject)：實(shí)現(xiàn)了抽象主題類(lèi)的接口方法
• 代理類(lèi)(Proxy)：實(shí)現(xiàn)了抽象主題類(lèi)的接口方法，內(nèi)部包含主題實(shí)現(xiàn)類(lèi)的邏輯， 同時(shí)還包含一些自身的擴(kuò)展操作。

代理模式與適配器模式相似。但適配器模式是轉(zhuǎn)換為新的接口，而代理模式不會(huì)改變?cè)薪涌凇?/p>

代碼示例：

/** 
 * @author 微信公眾號(hào)：微觀技術(shù) 
 */ 
public interface AbstractSubject { 
    void execute(); 
} 
 
public class RealSubject implements AbstractSubject { 
    @Override 
    public void execute() { 
        System.out.println("我是Tom哥，我要努力工作！"); 
    } 
} 
 
public class Proxy implements AbstractSubject { 
 
    private AbstractSubject abstractSubject; 
 
    public Proxy(AbstractSubject abstractSubject) { 
        this.abstractSubject = abstractSubject; 
    } 
 
    @Override 
    public void execute() { 
        System.out.println("老板給Tom哥分配工作了。。。"); 
        abstractSubject.execute(); 
    } 
} 

按使用職責(zé)分為靜態(tài)代理和動(dòng)態(tài)代理。

• 靜態(tài)代理，代理類(lèi)需要自己編寫(xiě)代碼完成。
• 動(dòng)態(tài)代理，代理類(lèi)通過(guò) Proxy#newProxyInstance(ClassLoader loader,Class[] interfaces,InvocationHandler h) 方法生成。
• JDK實(shí)現(xiàn)的代理中不管是靜態(tài)代理還是動(dòng)態(tài)代理，都是面向接口編程。CGLib可以不限制一定是接口。

優(yōu)點(diǎn)：

• 職責(zé)清晰
• 高擴(kuò)展，只要實(shí)現(xiàn)了接口，都可以用代理
• 智能化，動(dòng)態(tài)代理
• 降低了對(duì)象的直接耦合

適用場(chǎng)景：

• 遠(yuǎn)程代理。無(wú)法直接操作遠(yuǎn)程對(duì)象。比如：Dubbo、gRPC，提供遠(yuǎn)程服務(wù)，客戶(hù)端調(diào)用時(shí)需要走參數(shù)組裝、序列化、網(wǎng)絡(luò)傳輸?shù)炔僮?，這些通用邏輯都可以封裝到代理中，客戶(hù)端調(diào)用代理對(duì)象訪問(wèn)遠(yuǎn)程服務(wù)，就像調(diào)用本地對(duì)象一樣方便。
• 保護(hù)代理。當(dāng)客戶(hù)端通過(guò)代理對(duì)象訪問(wèn)原始對(duì)象時(shí)，代理對(duì)象會(huì)根據(jù)規(guī)則判斷客戶(hù)端是否有權(quán)限訪問(wèn)。比如：防火墻
• 日志代理。比如：日志監(jiān)控，正常業(yè)務(wù)訪問(wèn)時(shí)，調(diào)用代理，增加一些額外的日志記錄功能。
• 虛擬代理，適用于延遲初始化，用小對(duì)象表示大對(duì)象的場(chǎng)景，減少資源損耗，提升運(yùn)行速度。
• 不希望改變?cè)瓕?duì)象，但需要增加類(lèi)似于權(quán)限控制、日志、流控等附加功能時(shí)，可以使用代理模式。

6、責(zé)任鏈模式

定義：

責(zé)任鏈模式是一種行為設(shè)計(jì)模式，將所有請(qǐng)求的處理者通過(guò)前一對(duì)象記住其下一個(gè)對(duì)象的引用而連成一條鏈。收到請(qǐng)求后，每個(gè)處理者均可對(duì)請(qǐng)求進(jìn)行處理，或?qū)⑵鋫鬟f給鏈中的下個(gè)處理者。

責(zé)任鏈模式是對(duì)數(shù)據(jù)結(jié)構(gòu)中的鏈表結(jié)構(gòu)的具體應(yīng)用。

核心思路：

• 抽象處理者(Handler)：定義一個(gè)接口，內(nèi)部包含處理方法和下一個(gè)節(jié)點(diǎn)的引用對(duì)象
• 具體處理者(ConcreteHandler)：抽象處理者的實(shí)現(xiàn)子類(lèi)，判斷本次請(qǐng)求是否處理，如果需要?jiǎng)t處理，否則跳過(guò)，然后將請(qǐng)求轉(zhuǎn)發(fā)給下一個(gè)節(jié)點(diǎn)。

優(yōu)點(diǎn)：

• 降低了對(duì)象之間的耦合度。鏈上各個(gè)節(jié)點(diǎn)各司其職，通過(guò)上下文傳遞數(shù)據(jù)，避免直接依賴(lài)。
• 增強(qiáng)系統(tǒng)的可擴(kuò)展性。如果有新的業(yè)務(wù)需求，只需要在合適的位置增加一個(gè)鏈節(jié)點(diǎn)即可，滿(mǎn)足開(kāi)閉原則。
• 靈活性強(qiáng)。如果業(yè)務(wù)有變化，需要對(duì)工作流程做調(diào)整，只需要?jiǎng)討B(tài)調(diào)整鏈上節(jié)點(diǎn)的次序即可。甚至為了滿(mǎn)足多元化業(yè)務(wù)的多樣化需求，我們可以為不同的業(yè)務(wù)類(lèi)型定義自己的專(zhuān)屬執(zhí)行順序。
• 簡(jiǎn)化了對(duì)象之間的連接。每個(gè)對(duì)象只需保存下一個(gè)節(jié)點(diǎn)的引用，而不需保持所有節(jié)點(diǎn)。
• 責(zé)任明確。每個(gè)節(jié)點(diǎn)只需處理自己的工作，如果不處理則傳遞給下一個(gè)對(duì)象。明確各類(lèi)的責(zé)任范圍，符合類(lèi)的單一職責(zé)原則。

像我們常見(jiàn)的網(wǎng)關(guān)架構(gòu)推薦使用該模式，通過(guò)服務(wù)編排，可以自由地在任意位置添加或移除節(jié)點(diǎn)，滿(mǎn)足一系列個(gè)性化功能。

寫(xiě)在最后

設(shè)計(jì)模式很多人都學(xué)習(xí)過(guò)，但項(xiàng)目實(shí)戰(zhàn)時(shí)總是暈暈乎乎，原因在于沒(méi)有了解其核心是什么，底層邏輯是什么，《設(shè)計(jì)模式：可復(fù)用面向?qū)ο蟮幕A(chǔ)》有講過(guò)，

在設(shè)計(jì)中思考什么應(yīng)該變化，并封裝會(huì)發(fā)生變化的概念。

軟件架構(gòu)的精髓：找到變化，封裝變化。

業(yè)務(wù)千變?nèi)f化，沒(méi)有固定的編碼答案，千萬(wàn)不要硬套設(shè)計(jì)模式。無(wú)論選擇哪一種設(shè)計(jì)模式，盡量要能滿(mǎn)足SOLID原則，自我review是否滿(mǎn)足業(yè)務(wù)的持續(xù)擴(kuò)展性。有句話說(shuō)的好，“不論白貓黑貓，能抓老鼠就是好貓。”