享元模式的定義 定義: 使用共用對象可有效的支持大量的細粒度的對象 通俗的說, 就是將類的通用屬性抽出來,建立對象池,以達到限制對象數量的效果 上面定義中要求細粒度對象, 那麼不可避免的使得對象數量多且性質相近, 我們將這些對象的信息分為兩個部分: 內部狀態和外部狀態 說白了,內部狀態就是每個對象都 ...
享元模式的定義
定義: 使用共用對象可有效的支持大量的細粒度的對象
通俗的說, 就是將類的通用屬性抽出來,建立對象池,以達到限制對象數量的效果
上面定義中要求細粒度對象, 那麼不可避免的使得對象數量多且性質相近, 我們將這些對象的信息分為兩個部分: 內部狀態和外部狀態
- 內部狀態是對象可以共用出來的信息, 存儲在享元對象內部並且不會隨環境改變而改變. 如一個報考系統中的個人信息.
- 外部狀態時對象得以依賴的一個標記,是隨環境改變而改變的、不可以共用的狀態. 如報考系統中的報考科目. 享元模式通常以外部狀態為參考來限制對象產生數量
說白了,內部狀態就是每個對象都不同的屬性,外部狀態就是數量有限的屬性, 如性別隻有男女等
享元模式的類圖如下:
其中的角色:
- Flyweight 抽象享元角色: 簡單地說就是一個產品的抽象類,同時定義出對象的外部狀態和內部狀態的介面或實現
- ConcreteFlyweight 具體享元角色: 具體的一個產品類, 實現抽象角色定義的業務. 該角色需要註意的是內部狀態處理應該與環境無關,不應該初戀一個操作改變了內部狀態,同時修改了外部狀態, 這是角色不允許的
- FlyweightFactory 享元工廠: 職責非常簡單, 就是構造一個池容器,同時提供從池中獲得對象的方法
享元模式的目的在於運用共用技術,使得一些細粒度的對象可以共用
抽象享元角色代碼:
抽象享元角色一般為抽象類,在實際項目中一般是一個實現類, 它是描述一類事物的方法.在抽象角色中,一般需把外部狀態和內部狀態定義出來,避免子類的隨意擴展. 我們對外部狀態加上了final關鍵字, 防止意外發生.獲得外部狀態, 無意修改了一下, 池就混亂了.
在程式開發中, 確認只需要一次賦值的屬性則設置為final類型,避免無意修改導致邏輯混亂.
具體享元角色代碼:
享元工廠代碼:
享元模式的應用
享元模式的優點和缺點:
享元模式是一個非常簡單的模式, 它可以大大減少應用程式創建的對象,減低程式記憶體的占用,增強程式的性能,但它同時也提高了系統複雜性,需要分離出外部狀態和內部狀態, 而且外部狀態具有固化特性,不應該隨內部狀態改變而改變,否則導致系統的邏輯混亂
享元模式的使用場景:
- 系統中存在大量的相似對象
- 細粒度的對象都具備較接近的外部狀態,而且內部狀態與環境無關,也就是說對象沒有特定身份
- 需要緩衝池的場景
享元模式的擴展
1.線程安全的問題
當使用享元模式時, 對象池中的角色數量是一定的, 可能在拿的時候不同線程同時拿到同一個對象.這是就出現線程不安全的問題了
我們在使用享元模式時要註意這個問題. 我們在使用享元模式時,對象池中的享元對象儘量多, 多到足夠滿足業務為止
2.性能平衡
既然是面向對象編程, 我們何不將外部狀態抽離出來,定義為一個對象呢?
經過測試, 外部狀態使用對象要比使用基本類型效率低. 所以, 外部狀態最好以Java的基本類型作為標誌, 如stirng、int等, 可以大幅的提升效率
享元模式在Java API中也是隨處可見. 如Java的String就實現了對象池
需要說明一下的是,雖然可以使用享元模式實現對象池, 但是這兩者還是有比較大的差異, 對象池著重在對象的復用上,池中的每個對象是可替換的,從同一個池中獲得的A對象和B對象對客戶端來說是完全相同的,它主要解決復用,而享元模式主要解決對象的共用問題,如何建立多個可共用的細粒度對象是其關註的重點.