[轉]Python與設計模式

標籤：遊戲   計算   程式設計語言   方案   線程鎖   管理系統   開源軟體   解決   類比實現   

一、建立類設計模式

前言

什麼樣的程式員是一個好的程式員？學會很多門程式設計語言，就是一個好的程式員了嗎？事實上，學會一門程式設計語言不是一件很難的事，而“學會”一門程式設計語言是非常難的一件事。前一個“會”強調“能”，懂文法，能寫簡單的程式就算是前者的“會”了；後一個“會”，強調“精”，顯然，光能寫出“Hello World”並不算是後者的“會”，能熟練應用，並用程式設計語言解決各種問題，才算是真正的“會”。

點擊閱讀詳情

 

1、Python與設計模式--單例模式

匯流排是電腦各種功能組件或者裝置之間傳送資料、控制訊號等資訊的公用通訊解決方案之一。現假設有如下情境：某中央處理器（CPU）通過某種協議匯流排與一個號誌相連，號誌有64種顏色可以設定，中央處理器上運行著三個線程，都可以對這個號誌進行控制，並且可以獨立設定該號誌的顏色。抽象掉協議細節（用列印表示），如何?線程對訊號等的控制邏輯。

加線程鎖進行控制，無疑是最先想到的方法，但各個線程對鎖的控制，無疑加大了模組之間的耦合。下面，我們就用設計模式中的單例模式，來解決這個問題。

什麼是單例模式？單例模式是指：保證一個類僅有一個執行個體，並提供一個訪問它的全域訪問點。具體到此例中，匯流排對象，就是一個單例，它僅有一個執行個體，各個線程對匯流排的訪問只有一個全域訪問點，即惟一的執行個體。

點擊閱讀詳情

 

2、Python與設計模式--工廠類相關模式

想必大家一定見過類似於麥當勞自助點餐台一類的點餐系統吧。在一個大的觸摸顯示屏上，有三類可以選擇的上餐品：漢堡等主餐、小食、飲料。當我們選擇好自己需要的食物，支付完成後，訂單就產生了。下面，我們用今天的主角--原廠模式--來產生這些食物的邏輯主體。

點擊閱讀詳情

 

3、Python與設計模式--建造者模式

今天的例子，還是上一次談到的快餐點餐系統。只不過，今天我們從訂單的角度來構造這個系統。

點擊閱讀詳情

 

4、Python與設計模式--原型模式

大家如果用過類似於Photoshop的平面設計軟體，一定都知道圖層的概念。圖層概念的提出，使得設計、圖形修改等操作更加便利。設計師既可以修改和繪製當前映像對象，又可以保留其它映像對象，邏輯清晰，且可以及時得到反饋。本節內容，將以圖層為主角，介紹原型模式。

點擊閱讀詳情

 

二、結構類設計模式

1、Python與設計模式--代理模式

代理模式是一種使用頻率非常高的模式，在多個著名的開源軟體和當前多個著名的互連網產品背景程式中都有所應用。下面我們用一個抽象化的簡單例子，來說明代理模式。

點擊閱讀詳情

 

2、Python與設計模式--裝飾器模式

又提到了那個快餐點餐系統，不過今天我們只以其中的一個類作為主角：飲料類。

除了基本配置，快餐店賣可樂時，可以選擇加冰，如果加冰的話，要在原價上加0.3元；賣牛奶時，可以選擇加糖，如果加糖的話，要原價上加0.5元。怎麼解決這樣的問題？可以選擇裝飾器模式來解決這一類的問題。

點擊閱讀詳情

 

3、Python與設計模式--適配器模式

假設某公司A與某公司B需要合作，公司A需要訪問公司B的人員資訊，但公司A與公司B協議介面不同，該如何處理？

點擊閱讀詳情

 

4、Python與設計模式--門面模式

門面模式也叫面板模式，定義如下：要求一個子系統的外部與其內部的通訊必須通過一個統一的對象進行。門面模式提供一個高層次的介面，使得子系統更便於使用。門面模式注重“統一的對象”，也就是提供一個訪問子系統的介面。門面模式與之前說過的模板模式有類似的地方，都是對一些需要重複方法的封裝。但從本質上來說，是不同的。模板模式是對類本身的方法的封裝，其被封裝的方法也可以單獨使用；而門面模式，是對子系統的封裝，其被封裝的介面理論上是不會被單獨提出來用的。

點擊閱讀詳情

 

5、Python與設計模式--組合模式

組合模式也叫作部分-整體模式，其定義如下：將對象組合成樹形結構以表示“部分”和“整體”的階層，使得使用者對單個對象和組合對象的使用具有一致性。

點擊閱讀詳情

 

6、Python與設計模式--享元模式

享元模式定義如下：使用共用對象支援大量細粒度對象。大量細粒度的對象的支援共用，可能會涉及這些對象的兩類資訊：內部狀態資訊和外部狀態資訊。內部狀態資訊就是可共用出來的資訊，它們儲存在享元對象內部，不會隨著特定環境的改變而改變；外部狀態資訊就不可共用的資訊了。享元模式中只包含內部狀態資訊，而不應該包含外部狀態資訊。這點在設計業務架構時，應該有所考慮。

點擊閱讀詳情

 

7、Python與設計模式--橋樑模式

橋樑模式又叫橋接模式，定義如下：將抽象與實現解耦（注意此處的抽象和實現，並非抽象類別和實作類別的那種關係，而是一種角色的關係，這裡需要好好區分一下），可以使其獨立變化。在形如上例中，Pen只負責畫，但沒有形狀，它終究是不知道要畫什麼的，所以我們把它叫做抽象化角色；而Shape是具體的形狀，我們把它叫做實現化角色。抽象化角色和實現化角色是解耦的，這也就意味著，所謂的橋，就是抽象化角色的抽象類別和實現化角色的抽象類別之間的參考關聯性。

點擊閱讀詳情

 

三、行為類設計模式

1、Python與設計模式--策略模式

假設某司維護著一些客戶資料，需要在該司有新產品上市或者舉行新活動時通知客戶。現通知客戶的方式有兩種：簡訊通知、郵件通知。應如何設計該系統的客戶通知部分？為解決該問題，我們先構造客戶類，包括客戶常用的連絡方式和基本資料，同時也包括要發送的內容。

點擊閱讀詳情

 

2、Python與設計模式--責任鏈模式

假設有這麼一個請假系統：員工若想要請3天以內（包括3天的假），只需要直屬經理批准就可以了；如果想請3-7天，不僅需要直屬經理批准，部門經理需要最終批准；如果請假大於7天，不光要前兩個經理批准，也需要總經理最終批准。類似的系統相信大家都遇到過，那麼該如何?呢？

點擊閱讀詳情

 

3、Python與設計模式--命令模式

又是一個點餐系統（原諒作者的吃貨屬性）。不過這次的點餐系統是個飯店的點餐系統。飯店的點餐系統有什麼不同嘛？大夥想想看，在大多數飯店中，當服務員已經接到顧客的點單，錄入到系統中後，根據不同的菜品，會有不同的後台反應。比如，飯店有涼菜間、熱菜間、主食間，那當服務員將菜品錄入到系統中後，涼菜間會列印出顧客所點的涼菜條目，熱菜間會列印出顧客所點的熱菜條目，主食間會列印出主食條目。那這個系統的後台模式該如何設計？

點擊閱讀詳情

 

4、Python與設計模式--中介者模式

有一個手機倉儲管理系統，使用者有三方：銷售、倉庫管理員、採購。需求是：銷售一旦達成訂單，銷售人員會通過系統的銷售子系統部分通知倉儲子系統，倉儲子系統會將可出倉手機數量減少，同時通知採購管理子系統當前銷售訂單；倉儲子系統的庫存到達閾值以下，會通知銷售子系統和採購子系統，並督促採購子系統採購；採購完成後，採購人員會把採購資訊填入採購子系統，採購子系統會通知銷售子系統採購完成，並通知倉庫子系統增加庫存。

從需求描述來看，每個子系統都和其它子系統有所交流，在設計系統時，如果直接在一個子系統中整合對另兩個子系統的操作，一是耦合太大，二是不易擴充。為解決這類問題，我們需要引入一個新的角色-中介者-來將“網狀結構”精簡為“星形結構”。

點擊閱讀詳情

 

5、Python與設計模式--模板模式

投資股票是種常見的理財方式，我國股民越來越多，即時查詢股票的需求也越來越大。今天，我們通過一個簡單的股票查詢用戶端來認識一種簡單的設計模式：模板模式。

點擊閱讀詳情

 

6、Python與設計模式--迭代器模式

今天的主角是迭代器模式。在python中，迭代器並不用舉太多的例子，因為python中的迭代器應用實在太多了（不管是python還是其它很多的程式設計語言中，實際上迭代器都已經納入到了常用的庫或者包中）。而且在當前，也幾乎沒有人專門去開發一個迭代器，而是直接去使用list、string、set、dict等python可迭代對象，或者直接使用__iter__和next函數來實現迭代器。

點擊閱讀詳情

 

7、Python與設計模式--訪問者模式

假設一個藥房，有一些大夫，一個藥品劃價員和一個藥房管理員，它們通過一個藥房管理系統組織工作流程。大夫開出藥方後，藥品劃價員確定藥品是否正常，價格是否正確；通過後藥房管理員進行開藥處理。該系統可以如何?？最簡單的想法，是分別用一個一個if…else…把劃價員處理流程和藥房管理流程實現，這樣做的問題在於，擴充性不強，而且單一性不強，一旦有新藥的加入或者劃價流程、開藥流程有些變動，會牽扯比較多的改動。今天介紹一種解決這類問題的模式：訪問者模式。

點擊閱讀詳情

 

8、Python與設計模式--觀察者模式

在門面模式中，我們提到過火警通報器。在當時，我們關注的是通過封裝減少代碼重複。而今天，我們將從商務程序的實現角度，來再次實現該火警通報器。

點擊閱讀詳情

 

9、Python與設計模式--解譯器模式

要開發一個自動識別譜子的吉他模擬器，達到錄入譜即可按照譜發聲的效果。除了發聲裝置外（假設已完成），最重要的就是讀譜和譯譜能力了。分析其需求，整個過程大致上分可以分為兩部分：根據規則翻譯譜的內容；根據翻譯的內容演奏。我們用一個解譯器模型來完成這個功能。

點擊閱讀詳情

 

10、Python與設計模式--備忘錄模式

打過遊戲的朋友一定知道，大多數遊戲都有儲存進度的功能，如果一局遊戲下來，忘儲存了進度，那麼下次只能從上次進度點開始重新打了。一般情況下，儲存進度是要存在可持久化儲存空間上，本例中先以儲存在記憶體中來類比實現該情境的情形。

點擊閱讀詳情

 

11、Python與設計模式--狀態模式

電梯在我們周邊隨處可見，電梯的控制邏輯中心是由電梯控制器實現的。電梯的控制邏輯，即使簡單點設計，把狀態分成開門狀態，停止狀態和運行狀態，操作分成開門、關門、運行、停止，那流程也是很複雜的。首先，開門狀態不能開門、運行、停止；停止狀態不能關門，停止；運行狀態不能開門、關門、運行。要用一個一個if…else…實現，首先代碼混亂，不易維護；二是不易擴充。至於各種設計原則什麼的……

那該如何?？在上邊的邏輯中，每個操作僅僅是一個操作，狀態切換與操作是分離的，這也造成後來操作和狀態“相互配合”的“手忙腳亂”。如果把狀態抽象成一個類，每個狀態為一個子類，每個狀態實現什麼操作，不實現什麼操作，僅僅在這個類中具體實現就可以了。

點擊閱讀詳情

 

摘錄自：https://zhuanlan.zhihu.com/p/31675841

[轉]Python與設計模式