結(jié)構(gòu)型設(shè)計(jì)模式關(guān)注如何將類(lèi)或?qū)ο蠼M合成更大、更復(fù)雜的結(jié)構(gòu)，同時(shí)保持結(jié)構(gòu)的靈活性和高效性。在軟件工程，尤其是構(gòu)建互聯(lián)網(wǎng)信息服務(wù)（如Web應(yīng)用、API服務(wù)、微服務(wù)架構(gòu)）時(shí)，這些模式為解決模塊間的組織、通信和依賴關(guān)系提供了經(jīng)典方案。本文將聚焦7種結(jié)構(gòu)型模式的類(lèi)圖核心結(jié)構(gòu)，并選取其中4種，深入解析其在典型互聯(lián)網(wǎng)信息服務(wù)場(chǎng)景下的應(yīng)用。
一、 7種結(jié)構(gòu)型模式類(lèi)圖結(jié)構(gòu)精要
- 適配器模式 (Adapter):
- 核心結(jié)構(gòu): 包含一個(gè)
Target（目標(biāo)接口）、一個(gè)Adaptee（被適配者）和一個(gè)Adapter（適配器）。Adapter類(lèi)繼承或組合Adaptee，并實(shí)現(xiàn)Target接口，在其方法內(nèi)部調(diào)用Adaptee的特定方法，完成接口轉(zhuǎn)換。類(lèi)圖呈現(xiàn)為Adapter與Target之間為“實(shí)現(xiàn)”關(guān)系，與Adaptee之間為“組合”或“繼承”關(guān)系。
- 橋接模式 (Bridge):
- 核心結(jié)構(gòu): 將抽象部分（
Abstraction）與其實(shí)現(xiàn)部分（Implementor）分離。Abstraction維護(hù)一個(gè)對(duì)Implementor的引用。兩者都有各自的繼承體系（RefinedAbstraction和ConcreteImplementor），可以獨(dú)立變化。類(lèi)圖中表現(xiàn)為Abstraction聚合（菱形空心箭頭）一個(gè)Implementor。
- 組合模式 (Composite):
- 核心結(jié)構(gòu): 用于表示“部分-整體”的樹(shù)形結(jié)構(gòu)。定義了一個(gè)統(tǒng)一的組件接口
Component，聲明了add、remove、getChild等管理子組件的方法以及operation操作。Leaf（葉子）和Composite（容器）都實(shí)現(xiàn)Component接口。Composite對(duì)象持有Component對(duì)象的集合。類(lèi)圖呈現(xiàn)為Composite與Component之間是“聚合”關(guān)系，且兩者都實(shí)現(xiàn)/繼承自Component。
- 裝飾器模式 (Decorator):
- 核心結(jié)構(gòu): 動(dòng)態(tài)地給一個(gè)對(duì)象添加額外職責(zé)。
Decorator類(lèi)實(shí)現(xiàn)與Component相同的接口，并持有一個(gè)Component對(duì)象的引用。ConcreteDecorator繼承Decorator，在調(diào)用被裝飾對(duì)象的操作前后添加新行為。類(lèi)圖呈鏈?zhǔn)浇Y(jié)構(gòu)，Decorator聚合Component。
- 外觀模式 (Facade):
- 核心結(jié)構(gòu): 為子系統(tǒng)中的一組接口提供一個(gè)統(tǒng)一的高層接口（
Facade）。Facade類(lèi)知曉子系統(tǒng)中各個(gè)類(lèi)（SubsystemClasses）的職責(zé)，并將客戶端請(qǐng)求委派給相應(yīng)的子系統(tǒng)對(duì)象。類(lèi)圖中Facade與多個(gè)子系統(tǒng)類(lèi)之間為單向關(guān)聯(lián)。
- 享元模式 (Flyweight):
- 核心結(jié)構(gòu): 運(yùn)用共享技術(shù)有效支持大量細(xì)粒度對(duì)象。包含
Flyweight（抽象享元）、ConcreteFlyweight（具體享元，可共享）和UnsharedConcreteFlyweight（非共享享元）。FlyweightFactory（享元工廠）負(fù)責(zé)創(chuàng)建和管理享元對(duì)象。類(lèi)圖中工廠聚合享元池。
- 代理模式 (Proxy):
- 核心結(jié)構(gòu): 為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問(wèn)。
Proxy和RealSubject都實(shí)現(xiàn)Subject接口。Proxy持有對(duì)RealSubject的引用，并在其方法中可能進(jìn)行訪問(wèn)控制、懶加載、日志記錄等附加操作。類(lèi)圖中Proxy與RealSubject關(guān)聯(lián)，并共實(shí)現(xiàn)Subject。
二、 4種模式在互聯(lián)網(wǎng)信息服務(wù)中的典型應(yīng)用
互聯(lián)網(wǎng)信息服務(wù)通常具有高并發(fā)、分布式、模塊化等特點(diǎn)，以下四種結(jié)構(gòu)型模式應(yīng)用尤為廣泛：
- 適配器模式：整合異構(gòu)第三方服務(wù)
- 應(yīng)用場(chǎng)景: 系統(tǒng)需要接入多個(gè)外部服務(wù)提供商（如不同銀行的支付接口、多個(gè)地圖服務(wù)商的API、各類(lèi)云存儲(chǔ)服務(wù)）。這些服務(wù)接口規(guī)范各異。
- 應(yīng)用解析: 定義系統(tǒng)內(nèi)部統(tǒng)一的支付接口
PaymentService（Target）。為每個(gè)第三方服務(wù)（如AliPaySDK、WeChatPaySDK）創(chuàng)建對(duì)應(yīng)的適配器類(lèi)（如AliPayAdapter），實(shí)現(xiàn)PaymentService，并在其pay()方法內(nèi)部調(diào)用第三方SDK特有的方法，完成參數(shù)轉(zhuǎn)換和調(diào)用封裝。這樣，業(yè)務(wù)邏輯僅依賴統(tǒng)一的接口，與具體服務(wù)商解耦。
- 外觀模式：簡(jiǎn)化復(fù)雜微服務(wù)或模塊調(diào)用
- 應(yīng)用場(chǎng)景: 一個(gè)電商下單流程涉及用戶服務(wù)、庫(kù)存服務(wù)、優(yōu)惠券服務(wù)、支付服務(wù)等多個(gè)微服務(wù)或復(fù)雜模塊。前端或API網(wǎng)關(guān)直接調(diào)用這些服務(wù)繁瑣且易錯(cuò)。
- 應(yīng)用解析: 創(chuàng)建
OrderFacade（訂單外觀）類(lèi)。它內(nèi)部聚合或調(diào)用用戶、庫(kù)存、優(yōu)惠券、支付等子系統(tǒng)的客戶端或接口。對(duì)外提供一個(gè)簡(jiǎn)潔的方法如placeOrder(orderInfo)。在該方法內(nèi)，外觀類(lèi)按順序協(xié)調(diào)各個(gè)子系統(tǒng)的調(diào)用（驗(yàn)證用戶、扣減庫(kù)存、計(jì)算優(yōu)惠、發(fā)起支付），向客戶端隱藏了復(fù)雜的交互細(xì)節(jié)，提供了易用的接口，并降低了系統(tǒng)間的耦合度。
- 代理模式：實(shí)現(xiàn)訪問(wèn)控制與增強(qiáng)
- 應(yīng)用場(chǎng)景: 需要對(duì)敏感操作（如管理后臺(tái)API、付費(fèi)內(nèi)容訪問(wèn)）進(jìn)行權(quán)限校驗(yàn)；或需要對(duì)服務(wù)調(diào)用添加緩存、限流、日志、監(jiān)控等橫切關(guān)注點(diǎn)。
- 應(yīng)用解析:
- 保護(hù)代理: 定義
DataService接口及其真實(shí)實(shí)現(xiàn)RealDataService。創(chuàng)建AuthProxy，實(shí)現(xiàn)DataService并在其getSensitiveData()方法中首先檢查用戶token和權(quán)限，通過(guò)后才調(diào)用RealDataService的相應(yīng)方法。
- 遠(yuǎn)程代理/Cache代理: 在客戶端，代理可以代表一個(gè)位于遠(yuǎn)程的服務(wù)對(duì)象（如RPC存根）。或者，
CacheProxy在調(diào)用真實(shí)數(shù)據(jù)庫(kù)查詢服務(wù)前，先檢查本地/分布式緩存，命中則直接返回，否則調(diào)用真實(shí)服務(wù)并回填緩存。這在Web服務(wù)中極為常見(jiàn)。
- 裝飾器模式：靈活擴(kuò)展HTTP中間件/過(guò)濾器鏈
- 應(yīng)用場(chǎng)景: 在Web框架（如Express.js, Koa, Spring MVC）中，需要對(duì)HTTP請(qǐng)求/響應(yīng)處理流程添加多種功能，如GZIP壓縮、身份認(rèn)證、請(qǐng)求日志、數(shù)據(jù)格式化等，且這些功能需要能靈活組合。
- 應(yīng)用解析: 將核心的請(qǐng)求處理器定義為
Handler接口（Component）。基礎(chǔ)處理器ConcreteHandler處理核心業(yè)務(wù)。每個(gè)中間件（如AuthDecorator、LoggingDecorator、CompressionDecorator）都是一個(gè)裝飾器，實(shí)現(xiàn)Handler接口并持有下一個(gè)Handler的引用。在裝飾器的handleRequest(request)方法中，可以在調(diào)用下一個(gè)處理器之前（如進(jìn)行認(rèn)證）、之后（如記錄日志）或前后（如壓縮響應(yīng)）添加自己的邏輯。通過(guò)鏈?zhǔn)浇M合這些裝飾器，可以動(dòng)態(tài)地構(gòu)建出功能豐富的處理管道，符合“開(kāi)閉原則”。
###
理解結(jié)構(gòu)型模式的類(lèi)圖是掌握其靜態(tài)關(guān)系的基礎(chǔ)，而結(jié)合互聯(lián)網(wǎng)信息服務(wù)的具體場(chǎng)景（整合、簡(jiǎn)化、控制、擴(kuò)展）來(lái)理解其動(dòng)態(tài)行為和應(yīng)用價(jià)值，則能真正融會(huì)貫通。在系統(tǒng)設(shè)計(jì)，尤其是應(yīng)對(duì)服務(wù)集成、架構(gòu)簡(jiǎn)化、功能增強(qiáng)和流程擴(kuò)展等需求時(shí)，合理選用適配器、外觀、代理、裝飾器等模式，能顯著提升代碼的可維護(hù)性、可擴(kuò)展性和復(fù)用性。
