面向對象的代價

　　面向對象很好地解決了系統抽象性的問題，同時在大多數情況下，也不會損及系統的性能。但是，在某些特殊的應用中，由于對象的數量太大，采用面向對象會給系統帶來難以承受的內存開銷。比如圖形應用中的圖元等對象、字處理應用中的字符對象等。

　　動機（Motivation）

　　采用純粹對象方案的問題在于大量細粒度的對象會很快充斥在系統中，從而帶來很高的運行時代價——主要指內存需求方面的代價。如何在避免大量細粒度對象問題的同時，讓外部客戶程序仍然能夠透明地使用面向對象的方式來進行操作？

　　意圖（Intent）

　　運用共享技術有效地支持大量細粒度的對象。

　　　　　　　　　　　　——《設計模式》GoF　　

　　例說Flyweight應用

　　如果是對字符char使用享元模式，本來每個字符只占用2字節，而享元模式要使用指針，至少每個字符需要4字節，這樣就適得其反了，反而消耗了更多的內存資源。

　　但是字體就需要用享元模式了，因為它的大小比字符大得多，在我們這個例子中有12bytes，如果是它倍乘的話數量級就很大了，很消耗內存。

　　其實更精確地說，對于C#，每一個類還需要有一個虛表指針和做垃圾回收控制的空間，一共占8bytes。因為C#中每一個類都是繼承自object類，所以每個類都帶有虛函數和類型信息。所以Font類應該是20bytes的倍乘效應。在Charactor類中，char字符占2bytes；Font類型有個指針，占4bytes；還有Font里的20bytes；還有8bytes的虛表指針和垃圾回收；因為32位機器上有一個填充的效應，char字符還需要額外占用2bytes，需要補齊；因此Charactor類共占36bytes。在客戶代碼中，有100000個Charactor類，那么大約在會帶來3.6M的數據。如果是服務器程序，那么3M數據可以接受。但如果字符數量級再增加，那么開銷是不言而喻的。

　　改善結構：

　　Charactor類里的CFont屬性 

　　這里當我們使用Charactor的時候，我們設置它字體時，如果在它靜態的Hashtable里面已經有的話，我們就把指針直接指向它，就不要再去新建一個字體對象了

　　客戶代碼中第61行和63行，f1和f2占用兩塊不同的內存，但是到了68行和73行，我們實際上在內部透明的把它們轉化為讓它們只用f1一塊內存，f2的內存就不會再讓它持有。

　　要注意的是，在.NET里面使用字符串的時候，它實際上已經運用了享元模式，比如我們字符串里出了20個“Hello World”，實際上在系統里面只存了1個“Hello World”，其它的都是用指針指向它。這個前提當然是字符串的代價比指針大。

　　結構（Structure）

　　這種結構其實可以僅作為參考，它并不是一個作為絕對標準化的結構。基本思路實現是這樣，但是至于是否有必要放到一個靜態工廠來做，還值得商榷。像我們上面的例子就直接把它放在一個屬性里面去做。

　　Flyweight模式的幾個要點

　　面向對象很好地解決了抽象性的問題，但是作為一個運行在機器中的程序實體，我們需要考慮對象的代價問題。Flyweight設計模式主要解決面向對象的代價問題，一般不觸及面向對象的抽象性問題。Flyweight采用對象共享的做法來降低系統中對象的個數，從而降低細粒度對象給系統帶來的內存壓力。在具體實現方面，要注意對象狀態的處理。

　　對象的數量太大從而導致對象內存開銷加大——什么樣的數量才算大？這需要我們仔細的根據具體應用情況進行評估，而不能憑空臆斷。

　　.NET架構中的Flyweight應用

　　.NET在C#中有一個Code Behind機制，它表面有一個ASPx文件，背后又有一個cs文件，它的編譯過程實際上會把ASPx文件解析成C#文件，然后編譯成dll，在這個過程中，我們在ASPx中寫的任何html代碼都會轉化為literal control，literal control是一個一般的文本控件，它就表示html標記。當這些標記有一樣的時候，構建控件樹的時候就會用到Flyweight模式.

　　它的應用并不是那么平凡，只有在效率空間確實不高的時候我們才用它。

it知識庫：C#面向對象設計模式縱橫談：Flyweight 享元模式，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。