設計模式筆記(7 FLYWEIGHT & PROXY)

FLYWEIGHT(享元)
意圖：
運用共享技術有效地支持大量細粒度的對象。

適用性：
1.一個程序應用了大量的對象，造成很大的存儲開銷。
2.對象的大多數狀態可變爲外部狀態。
3.如果刪除對象的外部狀態，那麼可以用相對較少的公象對象取代很多組對象。
4.應用程序不依賴於對象標識

思考：
    上述的適用性和別的模式中介紹的不太一樣。基本上，適合使用FlyWeight模式的場景需要同時滿足上述四個條件，而別的模式大多隻要滿足適用性的一兩條，就可能適合採用該模式。
    從第一個適用性條件可以看出，這基本上屬於開銷優化的範圍。因此，除非事先有足夠的領域知識能夠加以預見，否則，是不必在早期設計中考慮使用該模式的。要想成功運用該模式，必須的一個條件是：除了那些外部狀態，餘下的狀態將是需要共享的。這也就意味着一般而言，FLYWEIGHT是隻讀的--變化的部分仍然需要加以分離出來－－從這個意義上來說，“享元”的中文翻譯更好地表達了這層意思。一個最好的情況是，共享的這些對象沒有外部狀態，且只作爲系統共享的只讀對象。關於第四條，可以認爲是一種補充說明，對象標識本身其實也是可以作爲變化的部分加以分離的。
    上面的討論強調了“只讀”，事實上，本模式並不要求FLYWEIGHT是隻讀的。但是，必須看到修改FLYWEIGHT的後果：這種影響是全局的，接近於全局變量的變種。某些時候也許我們確實需要這種全局的作用效果，但是濫用這一能力可能導致理解上的困難和程序行爲的判斷困難。FlyWeight的主要目的不在於此。
    通常，享元也並不能當作一個純粹的只讀對象，那麼，將變化的部分加以分離可能是必須的工作，也有必要對分離的效果加以評估再決定是否和如何運用FlyWeight模式。

PROXY（代理）
意圖：
爲其他對象提供一種代理以控制對這個對象的訪問。

適用性：
書中列出了幾種運用proxy的場景作爲適用性的說明：
1.遠程代理，爲一個不在同一地址空間的對象提供局部代理。
2.虛代理，根據需要創建很大的對象。
3.保護代理控制對原始對象的訪問。
4.智能引用，取代簡單指針，在訪問對象時提供附加操作。例如：智能指針；第一次訪問持久對象時，將它裝入內存；在訪問一個實際對象前，檢查其是否加鎖。

思考：
        相對於Decorator而言，通常Proxy是更重量級的。Proxy和Bridge模式也有很多相似之處：透過一個接口去訪問真正實現功能的對象。Decorator和Proxy的區別在於，Decorator目標僅僅在於增加某些方法的職責，並不打算全面掌控目標對象，另外，Decorator也並不確定自己將要修飾的可能會是什麼對象。Proxy模式則相反，Proxy需要全面瞭解甚至需要構建被代理對象，而Proxy和被代理對象之間的關係也是靜態決定的。有一點是相同的：一個實際對象既可以有多個Decorator,也可以有多個Proxy。
        Proxy和Bridge雖然有相似性，但是Bridge的目的僅僅是爲了維持接口和實現的各自演化，Bridge模式並不打算用來支持創建非常複雜的實現。Bridge模式的接口和實現在語意上是完全一致的。而Proxy模式，雖然一般而言Proxy和被代理對象之間具備一致的接口，但這完全是不必要的。當弱化Proxy的額外處理能力，強化Decorator的職責範圍，這三個模式之間的實現區別將會不那麼顯著，我們需要警惕的是，這三者之間的意圖則是差別非常巨大的。