享元模式的定義

定義: 使用共享物件可有效的支援大量的細粒度的物件

通俗的說, 就是將類的通用屬性抽出來,建立物件池,以達到限制物件數量的效果

上面定義中要求細粒度物件, 那麼不可避免的使得物件數量多且性質相近, 我們將這些物件的資訊分為兩個部分: 內部狀態和外部狀態

1. 內部狀態是物件可以共享出來的資訊, 儲存在享元物件內部並且不會隨環境改變而改變. 如一個報考系統中的個人資訊.
2. 外部狀態時物件得以依賴的一個標記,是隨環境改變而改變的、不可以共享的狀態. 如報考系統中的報考科目. 享元模式通常以外部狀態為參考來限制物件產生數量

說白了,內部狀態就是每個物件都不同的屬性,外部狀態就是數量有限的屬性, 如性別只有男女等

享元模式的類圖如下:

其中的角色:

1. Flyweight 抽象享元角色: 簡單地說就是一個產品的抽象類,同時定義出物件的外部狀態和內部狀態的介面或實現
2. ConcreteFlyweight 具體享元角色: 具體的一個產品類, 實現抽象角色定義的業務. 該角色需要注意的是內部狀態處理應該與環境無關,不應該初戀一個操作改變了內部狀態,同時修改了外部狀態, 這是角色不允許的
3. FlyweightFactory 享元工廠: 職責非常簡單, 就是構造一個池容器,同時提供從池中獲得物件的方法

享元模式的目的在於運用共享技術,使得一些細粒度的物件可以共享

抽象享元角色程式碼:

抽象享元角色一般為抽象類,在實際專案中一般是一個實現類, 它是描述一類事物的方法.在抽象角色中,一般需把外部狀態和內部狀態定義出來,避免子類的隨意擴充套件. 我們對外部狀態加上了final關鍵字, 防止意外發生.獲得外部狀態, 無意修改了一下, 池就混亂了.

在程式開發中, 確認只需要一次賦值的屬性則設定為final型別,避免無意修改導致邏輯混亂.

具體享元角色程式碼:

享元工廠程式碼:

享元模式的應用

享元模式的優點和缺點:

享元模式是一個非常簡單的模式, 它可以大大減少應用程式建立的物件,減低程式記憶體的佔用,增強程式的效能,但它同時也提高了系統複雜性,需要分離出外部狀態和內部狀態, 而且外部狀態具有固化特性,不應該隨內部狀態改變而改變,否則導致系統的邏輯混亂

享元模式的使用場景:

1. 系統中存在大量的相似物件
2. 細粒度的物件都具備較接近的外部狀態,而且內部狀態與環境無關,也就是說物件沒有特定身份
3. 需要緩衝池的場景

享元模式的擴充套件

1.執行緒安全的問題

當使用享元模式時, 物件池中的角色數量是一定的, 可能在拿的時候不同執行緒同時拿到同一個物件.這是就出現執行緒不安全的問題了

我們在使用享元模式時要注意這個問題. 我們在使用享元模式時,物件池中的享元物件儘量多, 多到足夠滿足業務為止

2.效能平衡

既然是面向物件程式設計, 我們何不將外部狀態抽離出來,定義為一個物件呢?

經過測試, 外部狀態使用物件要比使用基本型別效率低. 所以, 外部狀態最好以Java的基本型別作為標誌, 如stirng、int等, 可以大幅的提升效率

享元模式在Java API中也是隨處可見. 如Java的String就實現了物件池

需要說明一下的是,雖然可以使用享元模式實現物件池, 但是這兩者還是有比較大的差異, 物件池著重在物件的複用上,池中的每個物件是可替換的,從同一個池中獲得的A物件和B物件對客戶端來說是完全相同的,它主要解決複用,而享元模式主要解決物件的共享問題,如何建立多個可共享的細粒度物件是其關注的重點.

可以關注一下鄙人的公眾號, 謝謝各位了!