10-Python與設計模式–享元模式

一、網上咖啡選購平臺

假設有一個網上咖啡選購平臺，客戶可以在該平臺上下訂單訂購咖啡，平臺會根據用戶位置進行
線下配送。假設其咖啡對象構造如下：

class Coffee:name = ''price =0def __init__(self,name):self.name = nameself.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=namedef 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=nameself.coffee_factory=coffee_factorydef 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、享元模式中需要額外注意線程安全問題。