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
請參閱來源專案