Python 中一系列的設計模式和慣用語。
此專案 Fork 自 faif/python-patterns 。
主要的目的是做繁體中文的翻譯，不接受任何程式碼的修改，僅接受英文敘述變更，若有任何關於程式碼的疑問，請移駕至來源專案。
因貢獻方式不同，此專案的 README 將貢獻以下的欄位全數刪除，
創建型模式:
| 模式 | 描述 |
|---|---|
| abstract_factory | 使用特定工廠的通用函數 |
| borg | 實例中具有共享狀態的單例 |
| builder | 用建構器物件接收參數並回傳建構的物件，代替使用多個建構子 |
| factory | 委託專門的函數／方法來創建實例 |
| lazy_evaluation | Python 中延遲評估的屬性模式 |
| pool | 預先實例化並維護一組相同類型的實例 |
| prototype | 使用工廠和原型的克隆用於新實例（如果實例化是昂貴的） |
結構型模式:
| 模式 | 描述 |
|---|---|
| 3-tier | 資料<->商業邏輯<->演示分離（嚴謹的關係） |
| adapter | 使用白名單將一個介面調整到另一個介面 |
| bridge | 客戶端提供商中間人，以軟化介面變更 |
| composite | 讓客戶均勻對待個別物件和組合 |
| decorator | 使用其它功能包裝功能以影響輸出 |
| facade | 使用一個類別作為許多其他類的 API |
| flyweight | 透明地重用具有相似／相同狀態物件的存在實例 |
| front_controller | 單一處理程式請求進入應用程式 |
| mvc | 模型<->視圖<->控制器（非嚴謹關係） |
| proxy | 一個物件將操作導引到其它東西 |
行為型模式:
| 模式 | 描述 |
|---|---|
| chain_of_responsibility | 應用一系列連續的處理程序來嘗試和處理數據 |
| catalog | 一般方法會根據建構參數調用不同的專用方法 |
| chaining_method | 繼續回調下一個物件方法 |
| command | 捆綁命令和參數以便稍後調用 |
| iterator | 遍歷容器並訪問容器的元素 |
| mediator | 一個知道如何連接其他物件並充當代理的物件 |
| memento | 生成一個可用於回傳先前狀態的不透明令牌 |
| observer | 提供回調給資料的事件／變更通知 |
| publish_subscribe | 一個來源將事件／資料聯合到註冊的監聽器 |
| registry | 持續追蹤給定類別的所有子類別 |
| specification | 可以通過使用布林邏輯將商業規則鏈接在一起來重新組合商業規則 |
| state | 邏輯被組織成離散數量的潛在狀態和可以轉換到的下一個狀態 |
| strategy | 對同一資料的可選操作 |
| template | 一個物件強加一個結構，但用可插入的組件 |
| visitor | 為集合的所有物品調用回調 |
可測試性設計模式:
| 模式 | 描述 |
|---|---|
| dependency_injection | 依賴注入的 3 種變體 |
基本型模式:
| 模式 | 描述 |
|---|---|
| delegation_pattern | 物件通過委託給第二個物件（代表）來處理請求 |
其它:
| 模式 | 描述 |
|---|---|
| blackboard | 建築模型，匯集不同子系統的知識，建構解決方案，AI 方法 - 非四人幫設計模式 |
| graph_search | 圖形演算法 - 非四人幫設計模式 |
| hsm | 分層狀態機 - 非四人幫設計模式 |
Design Patterns in Python by Peter Ullrich
Sebastian Buczyński - Why you don't need design patterns in Python?
Pluggable Libs Through Design Patterns
請參閱來源專案