前言

本文為datawhale2022年12月組隊(duì)學(xué)習(xí)《大話設(shè)計(jì)模式》task6打卡學(xué)習(xí)。
【教程地址】https://github.com/datawhalechina/sweetalk-design-pattern

專業(yè)領(lǐng)域包括成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、電子商務(wù)商城網(wǎng)站建設(shè)、微信營銷、系統(tǒng)平臺開發(fā)， 與其他網(wǎng)站設(shè)計(jì)及系統(tǒng)開發(fā)公司不同，成都創(chuàng)新互聯(lián)公司的整合解決方案結(jié)合了幫做網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗(yàn)和互聯(lián)網(wǎng)整合營銷的理念，并將策略和執(zhí)行緊密結(jié)合，為客戶提供全網(wǎng)互聯(lián)網(wǎng)整合方案。一、橋接模式 1.1 基本定義

橋接模式（Bridge Pattern）又稱為柄體(Handle and Body)模式或接口(Interfce)模式，是將抽象部分與其實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。

1.2 問題引入

有不同品牌的手機(jī)，同時這些手機(jī)上還要安裝不同的應(yīng)用軟件，考慮在需要不斷增加軟件的情況下，如果設(shè)計(jì)相應(yīng)的抽象類。
需要注意對于不同品牌的手機(jī)，軟件基本無法兼容。因此如果手機(jī)需要增加軟件，就需要針對不同品牌的手機(jī)分別實(shí)現(xiàn)軟件功能。

1.2.1 問題分析

實(shí)現(xiàn)該問題的程序通常會采用繼承方式設(shè)計(jì)，那么父類和子類之間會具有非常緊密的依賴關(guān)系，父類中的任何變化都會影響子類，子類繼承的實(shí)現(xiàn)如果無法解決新需求就必須重寫或替換父類。如此設(shè)計(jì)會導(dǎo)致類爆炸問題，并且擴(kuò)展不靈活。

1.2.2 問題解決

考慮到單獨(dú)使用品牌或單獨(dú)使用軟件作為抽象類，都會在有新的需求來臨后使得父類必須重寫。因此需要使用合成/聚合原則代替類繼承思想設(shè)計(jì)程序，是應(yīng)該有個“手機(jī)品牌”抽象類和“手機(jī)軟件”抽象類，讓不同的品牌和功能都分別繼承于它們，這樣要增加新的品牌或新的功能都不用影響其他類了。結(jié)構(gòu)圖：

在工程中，包括以下四個角色：

• Abstraction（抽象類）：用于定義抽象類的接口，其中定義了一個具有關(guān)聯(lián)關(guān)系的Implementor 的對象。
• RefinedAbstraction（擴(kuò)充抽象類）：繼承并實(shí)現(xiàn)抽象類中的接口，并在其中調(diào)用Implementor 對象的相關(guān)業(yè)務(wù)方法。
• Implementor（實(shí)現(xiàn)類）：用于定義實(shí)現(xiàn)類的接口，提供基本的業(yè)務(wù)方法供抽象類調(diào)用，以完成復(fù)雜的操作。
• ConcreteImplementor（具體實(shí)現(xiàn)類）：繼承并實(shí)現(xiàn) Implementor 的接口，在不同的具體實(shí)現(xiàn)類中提供不同的操作方法，通過向上轉(zhuǎn)型的方式完成方法的調(diào)用。

1.2.3 代碼實(shí)現(xiàn)

官方源碼鏈接：
橋接模式Java實(shí)現(xiàn)
橋接模式python實(shí)現(xiàn)

1.3 應(yīng)用場景

客觀來說這個剛接觸確實(shí)很難直接應(yīng)用，但是一旦理解透徹對于面向?qū)ο笤O(shè)計(jì)有非常大的幫助。有以下情況，可以嘗試使用：

• 1.“抽象部分”和“實(shí)現(xiàn)部分”可以以繼承的方式獨(dú)立擴(kuò)展而互不影響，在程序運(yùn)行時可以動態(tài)將一個抽象化子類的對象和一個實(shí)現(xiàn)化子類的對象進(jìn)行組合，即系統(tǒng)需要對抽象化角色和實(shí)現(xiàn)化角色進(jìn)行動態(tài)耦合。
• 2.一個類存在兩個（或多個）獨(dú)立變化的維度，且這兩個（或多個）維度都需要獨(dú)立進(jìn)行擴(kuò)展。
• 3.對于那些不希望使用繼承或因?yàn)槎鄬永^承導(dǎo)致系統(tǒng)類的個數(shù)急劇增加的系統(tǒng)，橋接模式尤為適用。

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

• 在很多情況下，橋接模式可以取代多層繼承方案，多層繼承方案違背了“單一職責(zé)原則”，復(fù)用性較差，且類的個數(shù)非常多，橋接模式是比多層繼承方案更好的解決方法，它避免了繼承導(dǎo)致的類爆炸問題。
• 具備靈活的可擴(kuò)展性，在兩個變化維度中任意擴(kuò)展一個維度，都不需要修改原有系統(tǒng)，符合“開閉原則”。

1.4.2 缺點(diǎn)

• 將抽象和實(shí)現(xiàn)分離會增加設(shè)計(jì)的難度，由于關(guān)聯(lián)關(guān)系建立在抽象層，要求開發(fā)者一開始就針對抽象層進(jìn)行設(shè)計(jì)與編程。
• 橋接模式要求正確識別出系統(tǒng)中兩個獨(dú)立變化的維度，因此其使用范圍具有一定的局限性，如何正確識別兩個獨(dú)立維度也需要一定的經(jīng)驗(yàn)積累。

二、職責(zé)鏈模式 2.1 基本定義

職責(zé)鏈模式（Chain of Responsibility）也叫責(zé)任鏈模式，是一種對象行為型模式。為了避免請求發(fā)送者與多個請求處理者耦合在一起，于是將所有請求的處理者通過前一對象記住其下一個對象的引用而連成一條鏈；當(dāng)有請求發(fā)生時，可將請求沿著這條鏈傳遞，直到有對象處理它為止。
職責(zé)鏈模式核心是解決服務(wù)中先后執(zhí)行處理關(guān)系，從而降低請求發(fā)送者和接受者之間的耦合關(guān)系。類似于擊鼓傳花。

2.2 問題引入

要用程序?qū)崿F(xiàn)加薪、請假申請等需要層層審批的場景。比如向經(jīng)理提加薪申請，經(jīng)理沒權(quán)利然后向總監(jiān)上報，總監(jiān)沒權(quán)限然后向總經(jīng)理匯報等。

2.2.1 問題分析

如果將管理者創(chuàng)建成為一個類，那么該類會具有太多的責(zé)任，比如經(jīng)理、總監(jiān)以及總經(jīng)理的審批和上報功能，就違背了單一職責(zé)原則。而且以后的需求可能會增加新的管理類別，比如項(xiàng)目經(jīng)理、部門經(jīng)理、人事總監(jiān)等，那么就勢必會修改管理者類以完成擴(kuò)展，就違背了開放封閉原則。

2.2.2 問題解決

將公司管理者的類別變成管理者的子類，可以通過多態(tài)性來化解分支帶來的僵化。然后通過不同管理者之間建立管理關(guān)系實(shí)現(xiàn)請求的傳遞，使得請求的發(fā)送者和接收者解耦，可以讓各服務(wù)模塊更加清晰。處理者負(fù)責(zé)處理請求，客戶只需要將請求發(fā)送到職責(zé)鏈，無需關(guān)心具體的處理細(xì)節(jié)。

其中有兩個關(guān)鍵類：

• Handler(請求類)：用于定義一個處理請示的接口。
• ConcreteHandler(具體處理者類)：處理它所負(fù)責(zé)的請求，可訪問它的后繼者，如果能夠處理就處理，否則就將請求轉(zhuǎn)發(fā)給它的后繼者。

2.2.3 代碼實(shí)現(xiàn)

官方源碼鏈接：
職責(zé)鏈模式Java實(shí)現(xiàn)
職責(zé)鏈模式python實(shí)現(xiàn)

2.3 應(yīng)用場景：

責(zé)任鏈模式通常在以下幾種情況使用。

• 1.有多個對象可以處理一個請求，哪個對象處理該請求由運(yùn)行時刻自動確定。
• 2.可動態(tài)指定一組對象處理請求，或添加新的處理者。
• 3.在不明確指定請求處理者的情況下，向多個處理者中的一個提交請求。

2.4 優(yōu)缺點(diǎn) 2.4.1 優(yōu)點(diǎn)

• 能夠簡化對象的相互連接，接收者和發(fā)送者都沒有對方的明確信息，且鏈中的對象也不知道鏈的結(jié)構(gòu)。
• 避免了請求的發(fā)送者和接受者之間的耦合關(guān)系。
• 能夠隨時修改請求的結(jié)構(gòu)，增強(qiáng)了給對象指派職責(zé)的靈活性

2.4.2 缺點(diǎn)

• 請求可能到了鏈的末端都得不到處理，或者因?yàn)闆]有正確配置得不到處理。
• 較長的責(zé)任鏈可能會影響到系統(tǒng)的性能。

三、中介者模式 3.1 基本定義

中介者模式（Mediator Pattern）又叫又叫做調(diào)停者模式。它提供了一個中介類，用一個中介對象來封裝一系列的對象交互。
中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們的交互。中介者模式屬于行為型模式，用來降低多個對象和類之間的通信復(fù)雜性。

3.2 問題引入

剛進(jìn)公司的新人需求其他部門同事幫忙是有困難的，但是通過主管協(xié)調(diào)就會簡單許多。

3.2.1 問題分析

將系統(tǒng)分割成許多對象通?？梢栽黾悠鋸?fù)用性，但是對象之間大量的連接又使得對象之間的耦合性更強(qiáng)，導(dǎo)致對系統(tǒng)的行為進(jìn)行較大的改動就比較困難。

3.2.2 問題解決

通過中介者對象，可以將系統(tǒng)的網(wǎng)狀結(jié)構(gòu)變成以中介者為中心的星型結(jié)構(gòu)，使得對象之間的耦合度變低、擴(kuò)展性增強(qiáng)，系統(tǒng)的結(jié)構(gòu)不會因?yàn)樾聦ο蟮囊朐斐纱罅康男薷墓ぷ鳌?br />在工程中，有以下四個關(guān)鍵類：

• Mediator(抽象中介者類)：定義了同事對象到中介者對象的接口。
• ConcreteMediator(具體中介者對象)：實(shí)現(xiàn)抽象類的方法，知道所有具體同事類，并從具體同事接受消息，向其他具體同事發(fā)送命令。
• Colleague(抽象同時類)：用于定義抽象的同事對象。
• ConcreteColleague(具體同時類)：每個具體同事只知道自己的行為，而不了解其他同事類的情況，但是他們認(rèn)識終結(jié)者對象。

3.2.3 代碼實(shí)現(xiàn)

官方源碼鏈接：
中介者模式Java實(shí)現(xiàn)
中介者模式python實(shí)現(xiàn)

3.3 應(yīng)用場景

中介者模式一般應(yīng)用于一組對象以定義良好但是復(fù)雜的方式進(jìn)行通信的場合。以及想定制一個分布在多個類中的行為，而又不想生成太多的子類的場合。

3.4 優(yōu)缺點(diǎn) 3.4.1 優(yōu)點(diǎn)

• 中介者減少了各個業(yè)務(wù)類的耦合，使得可以獨(dú)立的改變和復(fù)用各個業(yè)務(wù)類和中介者類。
• 中介者的實(shí)現(xiàn)類控制了集中化，把對象群交互的復(fù)雜性變?yōu)橹薪檎叩膹?fù)雜性。
• 當(dāng)系統(tǒng)出現(xiàn)多對多交互復(fù)雜的對象群，可以考慮使用中介這模式。

3.4.2 缺點(diǎn)

中介者會變得龐大且復(fù)雜，原本多個對象直接的相互依賴變成了中介者和多個同事類的依賴關(guān)系，同事類越多，中介者的邏輯就越復(fù)雜。

參考

[1] datawhale大話設(shè)計(jì)模式教程云 - GitHub
[2] 秒懂設(shè)計(jì)模式之橋接模式（Bridge Pattern）
[3] 設(shè)計(jì)模式（十四）中介者模式

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

網(wǎng)頁標(biāo)題：設(shè)計(jì)模式-橋接、職責(zé)鏈、中介-創(chuàng)新互聯(lián)
網(wǎng)站URL：http://weahome.cn/article/gseci.html