舉個圍棋的例子，圍棋的棋盤共有361格，即可放361個棋子。現在要實現乙個圍棋程式，該怎麼辦呢？首先要考慮的是棋子棋盤的實現，可以定義乙個棋子的類，成員變數包括棋子的顏色、形狀、位置等資訊，另外再定義乙個棋盤的類，成員變數中有個容器，用於存放棋子的物件。下面給出**表示：
棋子的定義，當然棋子的屬性除了顏色和位置，還有其他的，這裡略去。這兩個屬性足以說明問題。
享元模式的uml圖，以圍棋為例。棋盤中含兩個共享的物件，黑棋子和白棋子，所有棋子的外在屬性都存放在單獨的容器中。
[img]
//棋子顏色
enum piececolor ;
//棋子位置
struct piecepos
};//棋子定義
class piece
~piece() {}
virtual void draw() {}
};class blackpiece: public piece
~blackpiece() {}
void draw()
~pieceboard()
void setpiece(piececolor color, piecepos pos) //一步棋，在棋盤上放一顆棋子
else
m_vecpiece.push_back(piece); //加入容器中
}void clear() //釋放記憶體
};
int main()
可以發現，棋盤的容器中存放了已下的棋子，而每個棋子包含棋子的所有屬性。一盤棋往往需要含上百顆棋子，採用上面這種實現，占用的空間太大了。如何改進呢？用享元模式。其定義為：運用共享技術有效地支援大量細粒度的物件。
在圍棋中，棋子就是大量細粒度的物件。其屬性有內在的，比如顏色、形狀等，也有外在的，比如在棋盤上的位置。內在的屬性是可以共享的，區分在於外在屬性。因此，可以這樣設計，只需定義兩個棋子的物件，一顆黑棋和一顆白棋，這兩個物件含棋子的內在屬性；棋子的外在屬性，即在棋盤上的位置可以提取出來，存放在單獨的容器中。相比之前的方案，現在容器中僅僅存放了位置屬性，而原來則是棋子物件。顯然，現在的方案大大減少了對於空間的需求。
關注pieceboard 的容器，之前是vectorm_vecpiece，現在是vectorm_vecpos。這裡是關鍵。
棋子的新定義，只包含內在屬性：
//棋子顏色
enum piececolor ;
//棋子位置
struct piecepos
};//棋子定義
class piece
~piece() {}
virtual void draw() {}
};class blackpiece: public piece
~blackpiece() {}
void draw()
};class whitepiece: public piece
~whitepiece() {}
void draw()
};
相應棋盤的定義為：
class pieceboard
~pieceboard()
void setpiece(piececolor color, piecepos pos)
else
m_vecpos.push_back(pos);}};
設計模式 11 享元模式 Flyweight
轉 問題 在物件導向系統的設計何實現中，建立物件是最為常見的操作。這裡面就有乙個問題 如果乙個應用程式使用了太多的物件，就會造成很大的儲存開銷。特別是對於大量輕量級 細 粒度 的物件，比如在文件編輯器的設計過程中，我們如果為沒有字母建立乙個物件的話，系統可能會因為大量的物件而造成儲存開銷的浪費。例如...
11 享元模式
一 享元模式 享元設計模式通過為相似物件引入資料共享來最小化記憶體使用，提公升效能。享元模式定義如下 使用共享物件支援大量細粒度物件。大量細粒度的物件的支援共享，可能會涉及這些物件的兩類資訊 內部狀態資訊和外部狀態資訊。內部狀態資訊就是可共享出來的資訊，它們儲存在享元物件內部，不會隨著特定環境的改變...
（11）享元模式
享元模式用於減少建立物件的數量，以減少記憶體占用和提高效能。享元模式嘗試重用現有的同類物件，如果未找到匹配的物件，則建立新物件。享元模式用得比較多的是池化技術，如常量池，執行緒池，連線池等等。import j a.util.hashmap import j a.util.map 享元模式 publi...