一、網上咖啡選購平臺
假設有一個網上咖啡選購平臺,客戶可以在該平臺上下訂單訂購咖啡,平臺會根據用戶位置進行線下配送。假設其咖啡對象構造如下:
class Coffee:
name = ''
price =0
def __init__(self,name):
self.name = name
self.price = len(name)#在實際業務中,咖啡價格應該是由配置表進行配置,或者調用接口獲取等方式得到,此處爲說明享元模式,將咖啡價格定爲名稱長度,只是一種簡化
def show(self):
print "Coffee Name:%s Price:%s"%(self.name,self.price)
其對應的顧客類如下:
class Customer:
name=""
def __init__(self,name):
self.name=name
def order(self,coffee_name):
print "%s ordered a cup of coffee:%s"%(self.name,coffee_name)
return Coffee(coffee_name)
按照一般的處理流程,用戶在網上預訂咖啡,其代表用戶的Customer類中生成一個Coffee類,直到交易流程結束。整個流程是沒有問題的。如果,隨着網站用戶越來越多,單位時間內購買咖啡的用戶也越來越多,併發量越來越大,對系統資源的消耗也會越來越大,極端情況下,會造成宕機等嚴重後果。此時,高效利用資源,就顯得非常重要了。
簡單分析下業務流程,高併發下用戶數量增加,而該模型下,每個用戶點一杯咖啡,就會產生一個咖啡實例,如果一種咖啡在該時間內被很多用戶點過,那麼就會產生很多同樣咖啡的實例。避免重複實例的出現,是節約系統資源的一個突破口。類似於單例模式,我們這裏在咖啡實例化前,增加一個控制實例化的類:咖啡工廠。
class CoffeeFactory():
coffee_dict = {}
def getCoffee(self, name):
if self.coffee_dict.has_key(name) == False:
self.coffee_dict[name] = Coffee(name)
return self.coffee_dict[name]
def getCoffeeCount(self):
return len(self.coffee_dict)
咖啡工廠中,getCoffeeCount直接返回當前實例個數。Customer類可以重寫下,如下:
class Customer:
coffee_factory=""
name=""
def __init__(self,name,coffee_factory):
self.name=name
self.coffee_factory=coffee_factory
def order(self,coffee_name):
print "%s ordered a cup of coffee:%s"%(self.name,coffee_name)
return self.coffee_factory.getCoffee(coffee_name)
假設業務中短時間內有多人訂了咖啡,業務模擬如下:
if __name__=="__main__":
coffee_factory=CoffeeFactory()
customer_1=Customer("A Client",coffee_factory)
customer_2=Customer("B Client",coffee_factory)
customer_3=Customer("C Client",coffee_factory)
c1_capp=customer_1.order("cappuccino")
c1_capp.show()
c2_mocha=customer_2.order("mocha")
c2_mocha.show()
c3_capp=customer_3.order("cappuccino")
c3_capp.show()
print "Num of Coffee Instance:%s"%coffee_factory.getCoffeeCount()
'''
打印如下:
A Client ordered a cup of coffee:cappuccino
Coffee Name:cappuccino Price:10
B Client ordered a cup of coffee:mocha
Coffee Name:mocha Price:5
C Client ordered a cup of coffee:cappuccino
Coffee Name:cappuccino Price:10
Num of Coffee Instance:2
'''
根據結果可以得知,該模式下三個用戶點了兩種咖啡,最終的咖啡實例爲2,而不是3。
二、享元模式
享元模式定義如下:使用共享對象支持大量細粒度對象。大量細粒度的對象的支持共享,可能會涉及這些對象的兩類信息:內部狀態信息和外部狀態信息。內部狀態信息就是可共享出來的信息,它們存儲在享元對象內部,不會隨着特定環境的改變而改變;外部狀態信息就不可共享的信息了。享元模式中只包含內部狀態信息,而不應該包含外部狀態信息。這點在設計業務架構時,應該有所考慮。
三、享元模式的優點和使用場景
優點:
1、減少重複對象,大大節約了系統資源。
使用場景:
1、系統中存在大量的相似對象時,可以選擇享元模式提高資源利用率。咖啡訂購平臺比較小,若假設一個電商平臺,每個買家和賣家建立起買賣關係後,買家對象和賣家對象都是佔用資源的。如果一個賣家同時與多個買家建立起買賣關係呢?此時享元模式的優勢就體現出來了;
2、需要緩衝池的場景中,可以使用享元模式。如進程池,線程池等技術,就可以使用享元模式(事實上,很多的池技術中已經使得了享元模式)。
四、享元模式的缺點
1、享元模式雖然節約了系統資源,但同時也提高了系統的複雜性,尤其當遇到外部狀態和內部狀態混在一起時,需要先將其進行分離,纔可以使用享元模式。否則,會引起邏輯混亂或業務風險;
2、享元模式中需要額外注意線程安全問題。