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