1、面向物件的缺點 

雖然OOP能很好的解決系統抽象的問題,並且在大多數的情況下,也不會損失系統的效能。但是在某些特殊的業務下,由於物件的數量太多,採用面向物件會給系統帶來難以承受的記憶體開銷.示例程式碼如下:

        /// <summary>
        /// Word文字的Font樣式
        /// </summary>
        public class Font //8+8(繼承object的虛表指標4個位元組、垃圾收集同步佔4個位元組)=16個位元組
        {
            public Font(string fontName, int
 
 size)
            {
                _fontName = fontName;
                _size = size;
            }
            string _fontName;//4個位元組,但是由於字串留用技術,可能實際建立大量這個物件的時候,可能會節省一些空間
            int _size;//4個位元組
        }

        /// <summary>
        /// Word文字物件
        /// </summary>
        public class
 
 Charactor //2+4(Font型別的引用指標)+16+2(32位作業系統的記憶體補齊)+8個位元組(繼承object的虛表指標4個位元組、垃圾收集同步佔4個位元組)=32個位元組
        {
            public Charactor(char c, Font font)
            {
                _c = c;
                _font = font;
            }
            char _c;//為一個Unicode字元,16位,佔2個位元組
            Font _font;//
 
16個位元組
        }

呼叫程式碼如下:

        public class ThirdSystem
        {
            public void Run()
            {

                long a = GC.GetTotalMemory(true);
                //建立10000000個Charactor物件大概要消耗32*10000000/1024/1024=343M
                int num = 10000000;
                //建立1千萬個Charactor物件
                var list = new List<Charactor>();//不消耗記憶體,如果使用ArrayList並指定初始化長度,會產生記憶體消耗
                for (var i = 0; i < num; i++)
                {
                    Charactor charactor = new Charactor('c', new Font("宋體", 6));
                    list.Add(charactor);
                }
                long b = GC.GetTotalMemory(true);
                long memoryConsume = b - a;
                Console.WriteLine(memoryConsume / 1024 / 1024);//實際輸出369,實際建立10000000個Charactor物件消耗了369M的記憶體空間
            }
        }

在客戶端系統生成了一千萬個物件例項,最後產生了369M的記憶體開銷,還單單是一個物件的例項的開銷,這種方式顯然不可取.

2、問題

採用物件方法來建立大量的物件例項,產生了很高的執行時代價-主要指記憶體方面的,那麼如何在採用面向物件的方式生成大量物件例項的同時,避免這種開銷呢?

關於這個問題,字串留用池的實現方式.提供了很好的借鑑.關於具體實現思路,請參考字串留用與字串池

3、解決方案

4、使用Flyweight享元模式的要點

(1)、該模式不涉及抽象性問題,也就是和抽象無關,它主要是解決面向物件的代價問題,在面向物件的過程中,建立了大量的物件例項,所產生的記憶體消耗.

(2)、該模式採用共享物件例項的方式來降低系統中物件的個數,也就是通過Hashtable等持有相同物件的引用降低細粒度物件例項帶給系統的壓力

(3)、因為採用持有相同物件引用的方式來共享物件,所以當一個物件發生改變時,所有的物件都會發生改變,類似陣列，所以要注意物件狀態的處理,不能盲目的修改.

(4)、該模式最好計算下整個系統的開銷,在根據實際情況去判斷是否要採用享元模式.