Python 正確性與可維護性反模式解析

– 11 分鐘閱讀

Python 的靈活性雖然讓開發者能快速實作功能，但也容易踩到一些坑。尤其在團隊協作和長期維護專案時，一些看似方便的寫法可能埋下難以察覺的錯誤，或讓程式碼變得難以理解和修改。例如，使用可變物件作為函式的預設引數，會導致每次呼叫都沿用前一次的結果，造成非預期的行為。直接存取類別的保護成員雖然可行，但破壞了封裝性，增加日後程式碼重構的難度。

在可維護性方面，萬用匯入看似簡潔，卻容易造成名稱空間汙染，難以追蹤變數來源。LBYL 風格的程式碼充斥著條件判斷，不如 EAFP 風格利使用案例外處理機制來得簡潔優雅。過度使用繼承會造成類別之間的緊密耦合，不利於程式碼的擴充套件和修改。而依賴全域變數來分享資料，則可能導致難以預料的副作用，增加除錯的困難。這些反模式雖然不會立即造成程式當機，但卻會在日後埋下隱患，增加維護成本。為了提升程式碼的品質和可維護性，開發者應避免這些反模式，並遵循最佳實務，例如使用不可變物件作為預設引數、透過公開介面存取類別成員、避免萬用匯入、優先使用 EAFP 風格、減少繼承的使用，以及避免濫用全域變數等。

正確性反模式（Correctness Anti-Patterns）解析

在 Python 程式設計中，某些寫法可能會導致程式執行結果不如預期或是產生難以預料的錯誤。其中一個常見的問題是使用可變的預設引數值。

可變預設引數值的陷阱

讓我們先來看一個範例。假設我們定義了一個名為 manipulate() 的函式，它有一個預設值為空列表 [] 的引數 mylist。這個函式會在 mylist 中追加一個字串 "test"，然後傳回該列表。

def manipulate(mylist=[]):
    mylist.append("test")
    return mylist

內容解密：

  • 此函式定義了一個帶有預設值的引數 mylist。
  • 預設值被設定為一個可變的資料結構——列表 []。
  • 每次呼叫該函式時，若未提供 mylist 的值，則會使用預設列表，並在其上追加 "test"。

接下來，我們再定義一個名為 better_manipulate() 的函式，其引數 mylist 的預設值為 None。如果 mylist 是 None，則將其設為空列表，再進行追加操作。

def better_manipulate(mylist=None):
    if not mylist:
        mylist = []
    mylist.append("test")
    return mylist

內容解密：

  • 這個函式同樣對 mylist 進行操作，但其預設值為 None。
  • 當 mylist 為 None（即未提供引數時），將其初始化為空列表。
  • 這種寫法避免了因使用可變預設引數而導致的意外行為。

讓我們測試這兩個函式：

if __name__ == "__main__":
    print("function manipulate()")
    print(manipulate())
    print(manipulate())
    print(manipulate())
    print("function better_manipulate()")
    print(better_manipulate())
    print(better_manipulate())

輸出結果如下：

function manipulate()
['test']
['test', 'test']
['test', 'test', 'test']
function better_manipulate()
['test']
['test']

從結果中可以看到，第一個函式由於使用了可變的預設引數，導致每次呼叫時都會保留前一次的結果，出現了累積效果。而第二個函式則表現出預期的行為，每次呼叫都傳回一個只包含一個 "test" 的列表。

從外部存取類別的保護成員

在 Python 中，以單一底線 _ 開頭的屬性或方法被視為保護成員，不建議從類別外部直接存取。正確的做法是透過類別的公開介面來存取這些成員。

考慮以下範例：

class Book:
    def __init__(self, title, author):
        self._title = title
        self._author = author

class BetterBook:
    def __init__(self, title, author):
        self._title = title
        self._author = author

    def presentation_line(self):
        return f"{self._title} by {self._author}"

在測試程式碼中：

if __name__ == "__main__":
    b1 = Book("Mastering Object-Oriented Python", "Steven F. Lott")
    print("Bad practice: Direct access of protected members")
    print(f"{b1._title} by {b1._author}")

    b2 = BetterBook("Python Algorithms", "Magnus Lie Hetland")
    print("Recommended: Access via the public interface")
    print(b2.presentation_line())

輸出結果：

Bad practice: Direct access of protected members
Mastering Object-Oriented Python by Steven F. Lott
Recommended: Access via the public interface
Python Algorithms by Magnus Lie Hetland

圖表翻譯：

此範例展示了直接存取保護成員與透過公開介面存取的差異。直接存取保護成員可能導致未來的維護問題，因為類別的實作可能會改變。透過公開介面（如 presentation_line() 方法）存取則提供了更好的封裝性和靈活性。

可維護性反模式（Maintainability Anti-Patterns）

這些反模式會使程式碼難以理解或維護。常見的問題包括：

  1. 使用萬用匯入（Wildcard Import）：這種匯入方式（如 from mymodule import *）會汙染名稱空間，使得追蹤變數或函式的來源變得困難。

  2. LBYL（Look Before You Leap） vs. EAFP（Easier to Ask for Forgiveness than Permission）：LBYL 風格會導致程式碼更為冗長，而 EAFP 則利用 Python 的例外處理機制，使程式碼更加簡潔和 Pythonic。

    例如，開啟檔案時，LBYL 風格的程式碼如下：

    if os.path.exists(filename):
    with open(filename) as f:
        print(f.text)

    而 EAFP 風格則是：

    try:
    with open(filename) as f:
        print(f.text)
except FileNotFoundError:
    print("No file there")

  3. 過度使用繼承和緊耦合：這會使程式碼之間的依賴關係過於複雜，難以維護。

  4. 使用全域變數分享資料：全域變數可能導致意外的副作用，使程式碼更難理解和除錯。

Python 反模式解析：維護性與效能問題

在軟體開發過程中，某些程式設計模式或做法可能會導致程式碼難以維護或效能不佳。這些被稱為反模式（Anti-Patterns）的情況，應該盡量避免。本文將探討幾種常見的Python反模式，包括維護性反模式和效能反模式，並提出改進建議。

維護性反模式

維護性反模式主要影響程式碼的可讀性、可維護性和可擴充套件性。以下是一些常見的例子：

過度使用繼承和緊密耦合

繼承是物件導向程式設計（OOP）中的一個強大功能，但過度使用它可能會導致類別之間的緊密耦合，增加程式碼的複雜度，使其更難維護。

# 不推薦的做法
class GrandParent:
    pass

class Parent(GrandParent):
    pass

class Child(Parent):
    pass

更好的做法是使用組合（Composition）而不是繼承，以減少類別之間的耦合度。

# 推薦的做法
class Parent:
    pass

class Child:
    def __init__(self, parent):
        self.parent = parent

使用全域變數分享資料

全域變數可以在整個程式中存取，因此很容易被濫用於在函式之間分享資料。然而，這種做法可能導致預期外的全域狀態修改，並使程式碼在多執行緒環境中更容易出現問題。

# 不推薦的做法
counter = 0

def increment():
    global counter
    counter += 1

def reset():
    global counter
    counter = 0

更好的做法是將需要的資料作為引數傳遞給函式，或將狀態封裝在類別中。

# 推薦的做法
class Counter:
    def __init__(self):
        self.counter = 0

    def increment(self):
        self.counter += 1

    def reset(self):
        self.counter = 0

效能反模式

效能反模式會導致程式碼執行效率低下，尤其是在大型應用或資料密集型任務中。

不使用 .join() 連線字串

在迴圈中使用 + 或 += 連線字串會每次都建立新的字串物件，這是非常低效的。更好的做法是使用字串的 .join() 方法。

# 不推薦的做法
def concatenate(string_list):
    result = ""
    for item in string_list:
        result += item
    return result

# 推薦的做法
def better_concatenate(string_list):
    result = "".join(string_list)
    return result

使用全域變數進行快取

使用全域變數進行快取看似簡單快速，但實際上會導致可維護性差、資料一致性問題和快取生命週期管理困難等問題。更好的做法是使用專門的快取函式庫。

# 不推薦的做法
_cache = {}

def get_data(query):
    if query in _cache:
        return _cache[query]
    else:
        # 模擬耗時操作
        time.sleep(1)
        result = random.random()
        _cache[query] = result
        return result

快取機制最佳化：從全域變數到 functools.lru_cache

在軟體開發中，效能最佳化是一個重要的課題。適當的快取機制可以顯著提升應用程式的效能，減少不必要的運算開銷。本文將探討如何利用快取機制最佳化程式碼，從簡單的全域變數快取到使用 Python 的 functools.lru_cache 進行高效的快取管理。

使用全域變數實作快取

首先，我們來看一個簡單的使用全域變數實作快取的例子。以下是一個 Python 函式，它使用全域變數 _cache 來儲存已經計算過的結果：

_cache = {}

def get_data(query):
    if query in _cache:
        return _cache[query]
    result = perform_expensive_operation(query)
    _cache[query] = result
    return result

def perform_expensive_operation(user_id):
    time.sleep(random.uniform(0.5, 2.0))
    user_data = {
        1: {"name": "Alice", "email": "alice@example.com"},
        2: {"name": "Bob", "email": "bob@example.com"},
        3: {"name": "Charlie", "email": "charlie@example.com"},
    }
    result = user_data.get(user_id, {"error": "User not found"})
    return result

if __name__ == "__main__":
    print(get_data(1))
    print(get_data(1))

程式碼解析：

  1. _cache 字典：用於儲存已經計算過的結果，避免重複計算。
  2. get_data 函式：首先檢查 _cache 中是否已經有對應的結果。如果有，直接傳回快取結果；否則，呼叫 perform_expensive_operation 進行計算，並將結果存入 _cache。
  3. perform_expensive_operation 函式：模擬一個耗時的操作，例如查詢資料函式庫或進行複雜計算。

使用 functools.lru_cache 最佳化快取

雖然上述方法可以實作基本的快取功能，但它存在一些問題，例如需要手動管理快取的大小和生命週期。Python 的 functools.lru_cache 提供了一個更高效、更易用的快取解決方案。

import random
import time
from functools import lru_cache

@lru_cache(maxsize=100)
def get_data(user_id):
    return perform_expensive_operation(user_id)

def perform_expensive_operation(user_id):
    time.sleep(random.uniform(0.5, 2.0))
    user_data = {
        1: {"name": "Alice", "email": "alice@example.com"},
        2: {"name": "Bob", "email": "bob@example.com"},
        3: {"name": "Charlie", "email": "charlie@example.com"},
    }
    result = user_data.get(user_id, {"error": "User not found"})
    return result

if __name__ == "__main__":
    print(get_data(1))
    print(get_data(1))
    print(get_data(2))
    print(get_data(99))

程式碼解析：

  1. @lru_cache(maxsize=100) 裝飾器：為 get_data 函式新增 LRU（Least Recently Used）快取功能。maxsize 引數指定了快取的最大容量。
  2. get_data 函式：現在不需要手動檢查快取或儲存結果，lru_cache 自動處理這些細節。
  3. perform_expensive_operation 函式：保持不變，模擬耗時操作。

為什麼選擇 functools.lru_cache？

  1. 自動管理快取大小和生命週期：lru_cache 自動處理快取的過期和替換策略，無需手動干預。
  2. 執行緒安全：在多執行緒環境中，lru_cache 能夠有效防止多個執行緒同時修改快取導致的問題。
  3. 效能最佳化：使用高效的資料結構和演算法來管理快取，提升整體效能。

軟體設計模式索引詳解

軟體設計模式是軟體開發中的重要概念，提供了可重複使用的解決方案來應對常見的設計問題。本文將根據提供的索引內容，詳細介紹各類別軟體設計模式及其應用。

建立型模式

建立型模式主要關注物件的建立機制，旨在提高系統的靈活性和可擴充套件性。

Factory Method 模式

Factory Method 模式提供了一個建立物件的介面，但允許子類別決定例項化哪一個類別。實作上，透過定義一個工廠方法，讓子類別實作該方法來建立物件。

  • 實作範例：在遊戲開發中，不同的遊戲角色可以透過工廠方法建立。
  • 真實世界範例：資料函式庫連線的建立，可以根據不同的資料函式庫型別使用不同的工廠方法。

Prototype 模式

Prototype 模式透過複製現有的物件來建立新的物件，而不是透過新建物件的方式。

  • 實作範例：在圖形編輯器中，可以透過複製現有的圖形物件來建立新的圖形。
  • 真實世界範例：在生物學中，細胞的有絲分裂可以視為 Prototype 模式的應用。

結構型模式

結構型模式關注類別和物件的組合，旨在簡化系統的設計和提高系統的可維護性。

Decorator 模式

Decorator 模式允許向一個現有的物件新增新的功能，同時又不改變其結構。

  • 實作範例：在咖啡店中，可以透過 Decorator 模式向咖啡新增不同的調味料。
  • 真實世界範例：在 GUI 程式設計中，可以使用 Decorator 模式為元件新增邊框或捲軸。

Facade 模式

Facade 模式提供了一個統一的介面，用於存取子系統中的一組介面。

  • 實作範例：在家庭影院系統中，可以透過 Facade 模式簡化影音裝置的控制。
  • 真實世界範例：在銀行系統中，可以使用 Facade 模式簡化客戶的交易流程。

行為型模式

行為型模式關注物件之間的互動和責任分配，旨在提高系統的靈活性和可擴充套件性。

Observer 模式

Observer 模式定義了物件之間的一對多依賴關係，當一個物件改變狀態時，所有依賴於它的物件都會得到通知。

  • 實作範例：在氣象預報系統中，可以使用 Observer 模式通知不同的顯示裝置更新氣象資料。
  • 真實世界範例：在社交媒體中，當使用者發布新內容時，所有關注該使用者的人都會收到通知。

Strategy 模式

Strategy 模式定義了一系列演算法，並將每個演算法封裝起來，使它們可以互換。

  • 實作範例：在電商系統中，可以使用 Strategy 模式實作不同的折扣策略。
  • 真實世界範例：在導航系統中，可以使用 Strategy 模式提供不同的路線規劃策略。

其他模式

除了上述分類別外，還有一些其他的設計模式，如 Singleton 模式、Command 模式等，這些模式在特定的場景下非常有用。

Singleton 模式

Singleton 模式確保一個類別只有一個例項，並提供一個全域存取點。

  • 實作範例：在日誌記錄系統中，可以使用 Singleton 模式確保只有一個日誌記錄器例項。
  • 真實世界範例：在組態管理系統中，可以使用 Singleton 模式確保組態資料的全域唯一性。

設計模式索引

本索引提供了豐富的Python設計模式相關資訊，涵蓋了從基礎到進階的多種模式及其應用場景。以下內容將對索引中的關鍵設計模式進行深入解析和整理。

建立型設計模式

建立型模式主要處理物件的建立機制，旨在提升系統的靈活性和可擴充套件性。

  1. 單例模式（Singleton Pattern）

    • 實作方式：透過確保一個類別只有一個例項，並提供全域存取點。
    • 應用場景：日誌記錄、組態管理等需要全域唯一例項的場景。
    • 實務範例：資料函式庫連線池、系統組態管理。

  2. 其他建立型模式

    • 包括工廠模式、建造者模式等，這些模式用於簡化物件的建立過程。

結構型設計模式

結構型模式關注類別和物件的組合，以實作更大的結構。

  1. 介面卡模式（Adapter Pattern）

    • 目的：使原本不相容的介面能夠協同工作。
    • 實作方式：透過建立介面卡類別，將一個類別的介面轉換成客戶端所期待的介面。
    • 應用場景：第三方函式庫整合、舊系統相容等。

  2. 代理模式（Proxy Pattern）

    • 型別：虛擬代理、保護代理、智慧代理等。
    • 實作方式：建立代理物件來控制對原物件的存取。
    • 應用場景：延遲載入、存取控制、快取等。

  3. 裝飾器模式（Decorator Pattern）

    • 目的：動態地為物件新增新的行為或功能。
    • 實作方式：透過建立裝飾器類別來包裝原始物件。
    • 應用場景：日誌記錄、加密解密、快取等功能的動態新增。

行為型設計模式

行為型模式主要關注物件之間的互動和職責分配。

  1. 狀態模式（State Pattern）

    • 目的：允許物件在其內部狀態改變時改變其行為。
    • 實作方式：為每個狀態建立一個類別，封裝與該狀態相關的行為。
    • 應用場景：有限狀態機、工作流程管理等。

  2. 策略模式（Strategy Pattern）

    • 目的：定義一系列演算法，並使它們可以互換。
    • 實作方式：將演算法封裝在獨立的策略類別中。
    • 應用場景：排序演算法選擇、支付方式選擇等。

平行和非同步設計模式

平行和非同步模式旨在提高系統的效能和回應速度。

  1. 執行緒池模式（Thread Pool Pattern）

    • 目的：管理和重複使用執行緒，以減少執行緒建立和銷毀的開銷。
    • 實作方式：建立一個執行緒池，維護一定數量的執行緒。
    • 應用場景：網路請求處理、資料函式庫查詢等需要平行處理的任務。

  2. 限流模式（Throttling Pattern）

    • 目的：控制系統的處理速率，防止過載。
    • 實作方式：透過演算法限制在一定時間內的請求數量。
    • 應用場景：API限流、流量控制等。

SOLID原則

SOLID原則是一套指導軟體設計的原則，有助於開發出更具擴充套件性和維護性的系統。

  1. 單一職責原則（SRP）

    • 定義：一個類別應該只有一個引起它變化的原因。
    • 優點：提高類別的內聚性，降低耦合度。

  2. 開放封閉原則（OCP）

    • 定義：軟體實體應該對擴充套件開放，對修改封閉。
    • 優點：提高系統的可擴充套件性和可維護性。

其他重要概念

  • 服務登入檔（Service Registry）：用於管理和查詢服務例項的登入檔。
  • 邊車模式（Sidecar Pattern）：透過佈署一個輔助容器來增強主容器的功能。
  • 雙階段提交（Two-Phase Commit）：一種用於分散式事務管理的協定，確保資料的一致性。
玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。