設計模式-實現對象的複用——享元模式

1. 享元模式概述

當一個系統中運行時產生的對象數量太多, 將致使運行代價太高, 帶來系統性能降低的問題.

享元模式: 運用共享技術有效的支持大量細粒度對象的複用. 系統只使用少許的對象, 而這些對下行都很類似, 狀態變化很小, 能夠實現對象的屢次複用. 因爲享元模式要求可以共享對象必須是細粒度的對象, 所以又稱爲輕量級模式, 它是一種對象結構型模式.

在享元模式結構圖中包含以下幾個角色：

• Flyweight（抽象享元類）：一般是一個接口或抽象類，在抽象享元類中聲明瞭具體享元類公共的方法，這些方法能夠向外界提供享元對象的內部數據（內部狀態），同時也能夠經過這些方法來設置外部數據（外部狀態）。
• ConcreteFlyweight（具體享元類）：它實現了抽象享元類，其實例稱爲享元對象；在具體享元類中爲內部狀態提供了存儲空間。一般咱們能夠結合單例模式來設計具體享元類，爲每個具體享元類提供惟一的享元對象。
• UnsharedConcreteFlyweight（非共享具體享元類）：並非全部的抽象享元類的子類都須要被共享，不能被共享的子類可設計爲非共享具體享元類；當須要一個非共享具體享元類的對象時能夠直接經過實例化建立。
• FlyweightFactory（享元工廠類）：享元工廠類用於建立並管理享元對象，它針對抽象享元類編程，將各類類型的具體享元對象存儲在一個享元池中，享元池通常設計爲一個存儲「鍵值對」的集合（也能夠是其餘類型的集合），能夠結合工廠模式進行設計；當用戶請求一個具體享元對象時，享元工廠提供一個存儲在享元池中已建立的實例或者建立一個新的實例（若是不存在的話），返回新建立的實例並將其存儲在享元池中。

在享元模式中引入了享元工廠類，享元工廠類的做用在於提供一個用於存儲享元對象的享元池，當用戶須要對象時，首先從享元池中獲取，若是享元池中不存在，則建立一個新的享元對象返回給用戶，並在享元池中保存該新增對象。

2. 享元模式的Swift實現

這個設計模式在OC中的應用, 例如UITableViewCell的複用就是, 例如UICollectionViewCell的複用就是. 用的地方不太多, 可是用處仍是比較大的, 若是不適用這樣的方法減小對象的建立, 在滑動tableview時候確定會致使內存的暴增!

3. 單純享元模式和符合享元模式

3.1 單純享元模式

在單純享元模式中, 全部的具體享元類都是共享的, 不存在非共享的享元類.

3.2 複合享元模式

將一些單純享元對象使用組合模式加一組合, 能夠造成複合享元對象, 這樣的對象自己不能共享, 可是他們可以分解成單純享元對象, 然後者能夠共享. 複合膜是結構圖以下所示:

經過複合享元模式, 能夠確保享元類中包含的每一個單純享元類都有相同的外部狀態, 而這些單純享元內部狀態每每能夠不一樣. 若是但願多個內部狀態不一樣的享元對象設置相同的外部狀態, 能夠考慮使用複合享元模式.

4. 享元模式總結

當系統中存在大量相同或者類似的對象時候, 享元模式是一種較好的解決方案, 它經過共享技術實現相同或者類似的細粒度對象的複用, 從而節約了內存空間, 提升了系統性能. 相比其它結構型設計模式, 享元模式的使用頻率並非很高, 可是做爲一種以"節約內存, 提升性能"爲出發點的設計模式, 它在軟件開發中, 仍是獲得了必定程度上的應用.

4.1 主要優勢

1. 能夠極少的減小內存對象的數量, 使得相同或者類似的對象再內存中只保存一份, 從而能夠節約系統資源, 提升系統性能.
2. 享元模式的外部狀態相對獨立, 並且不會影響其內部狀態, 從而使得享元對象能夠在不一樣的環境中被共享.

4.2 主要缺點

1. 享元模式使得系統變得複雜, 須要分離內部狀態和外部狀態, 使得系統的邏輯複雜化.
2. 爲了使對象能夠共享, 享元模式須要將享元對象的部分狀態外部化, 而讀取外部狀態將使得運行時間變長.

4.3 使用場景

1. 一個系統中有大量相同或者類似的對象, 形成內存的大量耗費.
2. 對象的大部分狀態均可之外部化, 能夠將這些狀態傳入對象中.
3. 在使用享元模式時候須要維護一個存儲享元對象的享元池, 而這須要耗費必定的系統資源, 所以應當在須要重複使用享元對象時才值得使用享元模式.

Reference: http://blog.csdn.net/lovelion/article/details/7667781