🎯 什麼情境該想到我
當你「需要在『客戶端』和『真正的物件』之間插一個替身，用來控制對它的存取」的時候：可能是這個物件很貴要延後才建（虛擬代理）、要先檢查權限（保護代理）、它其實在遠端（遠端代理），或想順便做快取／引用計數（智慧代理）。
⚙️ 怎麼用（步驟 / 公式）
意圖：為另一個物件提供一個替身或佔位符，以控制對這個物件的存取。
主要參與者 / 結構：
- Subject（主題介面）：RealSubject 與 Proxy 共同的介面，讓兩者對客戶端可互換。
- RealSubject（真實主題）：代理所代表、真正做事的物件。
- Proxy（代理）：實作 Subject 介面，持有 RealSubject 的參照；在把呼叫轉發給它之前／之後插入控制邏輯（建立、權限檢查、快取、計數、遠端通訊等）。
- Client：只認得 Subject 介面，實際拿到的是 Proxy。
常見種類：虛擬代理（延遲建立昂貴物件）、保護代理（存取控制／權限）、遠端代理（代表遠端物件、封裝網路通訊）、智慧代理（引用計數、快取、鎖定等附加管理）。
做法要點：
- 讓 Proxy 與 RealSubject 實作同一 Subject 介面。
- Proxy 內部持有（或在需要時才建立）RealSubject。
- 在轉呼叫的前後加入所需的控制邏輯。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 多一層間接一定會增加回應時間與複雜度。
- 若沒有「控制存取」的需求，只是單純想加功能，那該用裝飾者而不是代理。
- 延遲載入等行為若隱藏得太深，可能造成難以預期的效能或時序問題。
🔗 相關工具
- 裝飾者模式 Decorator（結構幾乎相同，但代理意在「控制存取」，裝飾者意在「附加功能」）
- 配接器模式 Adapter（配接器換成不同介面；代理維持與真實物件相同的介面）
- 外觀模式 Facade（外觀為子系統提供不同的簡化介面；代理只是單一物件的同介面替身）
- 享元模式 Flyweight（都在取得物件的環節動手腳：享元共享實例、代理控管存取）
- 工具-針對介面編程（客戶端只依賴 Subject 介面，代理才能無縫替換）
- 設計模式