Design Pattern 設計模式 (3): Facade, Flyweight, Proxy, Chain of Responsibility

本站的主題是商業，創業，美食，葡萄酒，閱讀，網路科技。

這是我的 FB粉專以及 IG，我比較常使用 Threads，歡迎大家追蹤互動~

此篇文章會介紹 Facade, Flyweight, Proxy, and Chain of Responsibility patterns.

1. Facade Pattern
Facade pattern 的使用時機基本上就是當你的模組有很多 sub-module 時, 提供一個簡單的介面供系統調用. 架構上就是用一個大 class (即是 facade) 將 sub-module 們包裹起來, 此 facade 通常要負責 sub-module 們的生成與毀滅. 另外要注意的是 facade 要有將 sub-modules 與系統 decouple 的責任. Facade pattern 就個人的意見來說並不算是所謂的 “Design Pattern”, Facade Pattern 的精神只是將 sub-modules 包裹起來, 提供系統一個簡單的介面, 在此不再贅述.

2. Flyweight Pattern
使用時機: 當系統中不同 client 端可以共用 object 時, 以節省 memory cost.

多個 client 跟一個 factory query objects. 當 query 同一 object 時, ClientA, ClientB 應拿到實體為同一個的 object. object 的生成與消滅應由此 factory 負責.

另外[1]中提到
# UnsharedConcreteFlyweight 與 SharedConcreteFlyweight 的概念. UnsharedConcreteFlyweight 常常是 SharedConcreteFlyweight 的 aggregation.
# intrinsic/extrinsic state 的概念. SharedConcreteFlyweight 要有自己的 intrinsic state, 其是不隨 client 端的 context 改變的. 相對的, 調用 flyweight 時則須由外部傳 client context 進來, 即是 extrinsic state.

3. Proxy Pattern
使用時機: 當一 class 的多個 operation 工作內容需要更改時.

一 Proxy class 覆蓋多個或全部 Subject class 的函式, 此 Proxy 可以負責創造 Subject 或是只 keep reference. 制定架構規格時可以創造一 AbstractSubject, 令 Proxy 與 Subject 同時繼承之.

4. Chain of Responsibility
使用時機: 有任務是須要一個項目一個項目確認, 或是一關一關過時.