結構型設計模式關注如何將類或對象組合成更大、更復雜的結構,同時保持結構的靈活性和高效性。在軟件工程,尤其是構建互聯(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)設計,尤其是應對服務集成、架構簡化、功能增強和流程擴展等需求時,合理選用適配器、外觀、代理、裝飾器等模式,能顯著提升代碼的可維護性、可擴展性和復用性。