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