行為模式提供瞭解耦元件互動的抽象方法，提升系統靈活性。觀察者模式讓觀察者動態回應主體狀態變化，解決了傳統回呼整合的繁瑣問題。命令模式則將請求封裝成物件，解耦請求者和執行者，提高了系統擴充套件性和可讀性。這些模式在重構過程中能有效提升系統的靈活性與可維護性，避免系統僵化。更進一步，我們可以探討 Command、Mediator、Chain of Responsibility 和 State 四種設計模式，並提供程式碼範例說明如何應用這些模式重構行為邏輯。這些模式分別解決了動作封裝、元件互動管理、請求處理和狀態轉換等問題，提供更細緻的重構策略。最後，我們將以金融服務平台的重構案例，展示如何結合建立型、結構型和行為型模式，提升系統的靈活性和可維護性，並說明自動化測試在重構過程中的重要性。
9.7 行為模式提升系統行為的靈活性
行為模式重新定義了複雜系統中動作和互動的協調方式，提供了在不產生剛性耦合的情況下管理元件之間通訊的抽象方法。在重構過程中，這些模式有助於將單一控制流程轉變為靈活、動態和回應式的系統。深入理解行為模式可以幫助開發者根據不斷變化的需求調整程式碼，同時保持清晰度和可重用性。
觀察者模式（Observer Pattern）
觀察者模式是一種常見的行為模式，用於在重構過程中解耦主體和觀察者，使觀察者能夠動態註冊並對主體狀態變化做出反應。這種模式在事件驅動架構中尤其有用，因為舊程式碼可能包含繁瑣的回呼整合或與狀態更新緊密繫結的邏輯。
傳統實作的侷限性
class LegacySubject:
def __init__(self):
self.state = None
def update_state(self, new_state):
self.state = new_state
self.notify() # 硬編碼的通知過程
def notify(self):
# 直接呼叫預定義的函式
observer_a(self.state)
observer_b(self.state)
def observer_a(state):
print("Observer A received state:", state)
def observer_b(state):
print("Observer B received state:", state)
使用觀察者模式重構
class Subject:
def __init__(self):
self._observers = set()
self._state = None
def attach(self, observer: callable) -> None:
self._observers.add(observer)
def detach(self, observer: callable) -> None:
self._observers.discard(observer)
def notify(self) -> None:
for observer in self._observers:
observer(self._state)
def update_state(self, new_state):
self._state = new_state
self.notify()
# 重構後的用法
subject = Subject()
subject.attach(lambda state: print("Observer X received:", state))
subject.attach(lambda state: print("Observer Y received:", state))
subject.update_state("New dynamic state")
內容解密：
attach和detach方法：允許觀察者動態註冊和登出，增強了系統的靈活性。notify方法：遍歷所有註冊的觀察者並呼叫它們，實作瞭解耦。- Lambda 函式作為觀察者：展示了使用匿名函式註冊觀察者的靈活性。
命令模式（Command Pattern）
命令模式將請求封裝為物件，從而解耦請求者和執行者。這在重構舊系統時特別有用，因為舊系統中的動作處理通常嵌入條件陳述式中。命令模式將操作抽象為獨立的物件，這些物件封裝了執行所需的所有資訊，從而實作可復原操作、動態命令排程和任務佇列等功能。
傳統實作的侷限性
def execute_action(action, data):
if action == "create":
create_entity(data)
elif action == "update":
update_entity(data)
elif action == "delete":
delete_entity(data)
else:
raise ValueError("Unknown action")
這種實作方式存在以下問題：
- 擴充套件性差：新增動作需要修改
execute_action函式。 - 可讀性差：條件分支過多時，程式碼難以維護。
使用命令模式重構（範例待補充）
命令模式透過將每個動作封裝為獨立的命令物件來解決上述問題。每個命令物件實作相同的介面，但具體執行動作不同。這樣可以輕鬆新增或移除命令，而無需修改現有程式碼。
行為模式的優勢
行為模式（如觀察者模式和命令模式）透過提供靈活的互動機制，顯著提高了系統的可擴充套件性和可維護性。它們幫助開發者在不修改現有程式碼的情況下新增功能，從而減少了引入錯誤的風險。
重構行為邏輯：設計模式的應用
在軟體開發過程中，行為邏輯的重構是提升程式碼可維護性和擴充套件性的重要步驟。本文將介紹四種常見的設計模式：Command、Mediator、Chain of Responsibility和State，並展示如何利用這些模式對行為邏輯進行重構。
使用Command模式封裝動作
Command模式透過定義一個根據介面的命令類別和具體的命令類別，將動作封裝成物件。這種方式使得系統更具可維護性，因為操作邏輯被隔離在獨立的類別中。
程式碼範例：
from abc import ABC, abstractmethod
class Command(ABC):
@abstractmethod
def execute(self):
pass
class CreateCommand(Command):
def __init__(self, data):
self.data = data
def execute(self):
create_entity(self.data)
class UpdateCommand(Command):
def __init__(self, data):
self.data = data
def execute(self):
update_entity(self.data)
class DeleteCommand(Command):
def __init__(self, data):
self.data = data
def execute(self):
delete_entity(self.data)
COMMAND_REGISTRY = {
"create": CreateCommand,
"update": UpdateCommand,
"delete": DeleteCommand
}
def execute_action_refactored(action, data):
command_class = COMMAND_REGISTRY.get(action)
if not command_class:
raise ValueError("Unknown action")
command = command_class(data)
command.execute()
內容解密：
Command抽象基礎類別定義了execute抽象方法，所有具體命令類別必須實作此方法。CreateCommand、UpdateCommand和DeleteCommand是具體命令類別，分別封裝了建立、更新和刪除的操作。COMMAND_REGISTRY是一個字典，用於動態呼叫命令類別。execute_action_refactored函式透過查詢COMMAND_REGISTRY來建立並執行相應的命令物件。
使用Mediator模式集中管理互動
Mediator模式透過引入一個中介者物件，來集中管理多個物件之間的複雜互動，從而解耦原本直接相互依賴的元件。
程式碼範例：
class Mediator:
def __init__(self):
self.components = {}
def register(self, name: str, component):
self.components[name] = component
def notify(self, sender: str, message: str):
for name, component in self.components.items():
if name != sender:
component.receive(message)
class Component:
def __init__(self, mediator: Mediator, name: str):
self.mediator = mediator
self.name = name
mediator.register(name, self)
def send(self, message):
self.mediator.notify(self.name, message)
def receive(self, message):
print(f"Component {self.name} received: {message}")
# 建立中介者和元件
mediator = Mediator()
comp_a = Component(mediator, "A")
comp_b = Component(mediator, "B")
comp_a.send("Hello")
內容解密：
Mediator類別負責註冊元件並管理它們之間的互動。Component類別代表系統中的元件，它們透過Mediator進行通訊。- 當一個元件傳送訊息時，
Mediator負責將訊息轉發給其他註冊的元件。
使用Chain of Responsibility模式處理請求
Chain of Responsibility模式允許多個處理器按順序處理一個請求，這對於需要多步驟處理或具有不同處理策略的系統非常有用。
程式碼範例：
class Handler(ABC):
def __init__(self, successor=None):
self.successor = successor
@abstractmethod
def handle(self, request):
pass
class ConcreteHandler1(Handler):
def handle(self, request):
if request < 10:
return f"Handled by ConcreteHandler1: {request}"
elif self.successor:
return self.successor.handle(request)
return None
class ConcreteHandler2(Handler):
def handle(self, request):
if request < 20:
return f"Handled by ConcreteHandler2: {request}"
elif self.successor:
return self.successor.handle(request)
return None
# 建立處理鏈
handler_chain = ConcreteHandler1(ConcreteHandler2())
result = handler_chain.handle(15)
內容解密：
Handler抽象基礎類別定義了處理請求的介面，並包含一個指向後繼處理器的參照。ConcreteHandler1和ConcreteHandler2是具體的處理器，它們根據請求的值決定是否處理或傳遞給後繼者。- 處理鏈透過將處理器例項化並傳遞給下一個處理器來建立。
使用State模式管理狀態轉換
State模式將狀態特定的行為封裝在專門的類別中，使得物件能夠在不同狀態之間轉換，而無需使用複雜的條件判斷。
程式碼範例：
class State(ABC):
@abstractmethod
def handle(self, context):
pass
class ConcreteStateA(State):
def handle(self, context):
context.state = ConcreteStateB()
print("Transitioning from State A to State B")
class ConcreteStateB(State):
def handle(self, context):
context.state = ConcreteStateA()
print("Transitioning from State B to State A")
class Context:
def __init__(self, state: State):
self.state = state
def request(self):
self.state.handle(self)
內容解密：
State抽象基礎類別定義了狀態處理的介面。ConcreteStateA和ConcreteStateB代表具體的狀態，它們實作了狀態轉換的邏輯。Context類別維護當前的狀態，並根據當前狀態委託給相應的狀態物件進行處理。
行為重構的進階實踐與案例分析
行為重構的最佳實踐是透過迭代應用和嚴格的自動化測試來實作。進階開發者應結合變異測試（mutation testing）和根據屬性的測試（property-based testing）等技術，以確保重構後的行為正確性。此外，不同的行為模式可以相互結合，例如將命令模式（Command pattern）與中介者模式（Mediator）結合，實作一個非同步命令佇列，以協調分散式元件之間的執行。同樣地，觀察者模式（Observer pattern）可以與狀態模式（State pattern）結合，根據上下文狀態管理條件訂閱。
在這些模式中整合日誌記錄和錯誤處理至關重要。導向切面程式設計（Aspect-oriented programming）技術可以用來注入諸如指標收集或安全檢查等橫切關注點，而無需修改主要行為模式。這確保了在重構行為時，檢測工具保持一致且非侵入式。透過效能監控工具對這些系統進行效能分析，進一步保證了行為模式引入的靈活性不會降低執行階段效率。
行為重構的優勢
使用設計模式進行行為重構，最終會使程式碼更容易擴充套件、修改和理解。透過隔離互動協定、封裝請求和集中通訊，系統變得更具回應性和可維護性。行為模式使開發者能夠將不透明的控制流程轉變為透明、模組化的結構，每個元件的責任都清晰定義。這種方法不僅解決了技術債，還為未來的增強做好了準備，確保系統在不斷變化的需求面前保持敏捷，同時保持高水準的運作完整性。
案例研究：重構成功案例
現實中的重構專案通常能夠展示出規範應用設計模式的轉變潛力。在幾個大型系統中，團隊利用建立型、結構型和行為型模式對遺留程式碼進行了強大的改造。進階實踐者記錄了許多案例，這些案例表明系統性的重構不僅減少了技術債，還提高了可擴充套件性、可維護性和整體系統敏捷性。
金融服務平台的重構實踐
一個典型的案例涉及一個具有龐大遺留程式碼函式庫的金融服務平台，該平台經過十多年的演變。該系統負責處理交易資料並生成即時風險評估，但存在緊密耦合的模組和普遍的冗餘。重構工作首先佈署了一套全面的自動化測試，以捕捉平台的關鍵不變數。進階單元測試、整合測試和根據屬性的測試被整合到持續整合管道中，確保即使是微小的更新也可以安全地回復。
建立型模式的應用
重構團隊首先使用建立型模式隔離物件建立邏輯。將遍佈程式碼的直接例項化集中到工廠類別中。例如，將直接例項化各種風險模型物件的遺留程式碼部分重構為使用工廠方法（Factory Method）。原始程式碼如下：
def get_risk_model(type, parameters):
if type == "standard":
return StandardRiskModel(parameters)
elif type == "advanced":
return AdvancedRiskModel(parameters)
# 額外的直接例項化
這被系統性地替換為專門的工廠：
class RiskModelFactory:
def create_risk_model(self, model_type, parameters):
if model_type == "standard":
return StandardRiskModel(parameters)
elif model_type == "advanced":
return AdvancedRiskModel(parameters)
raise ValueError("Unknown model type")
factory = RiskModelFactory()
risk_model = factory.create_risk_model("standard", parameters)
結構型模式的應用
結構型模式進一步支援了該專案的重構敘事。原始架構具有多個相互纏繞的元件，形成了一個「大泥球」（big ball of mud）。外觀模式（Facade pattern）被用來封裝複雜的子系統，例如處理資料擷取、轉換和輸出生成的子系統。透過引入統一的外觀介面，團隊抽象掉了複雜的內部互動，從而實作了子系統的獨立測試和客戶端模組的更乾淨API。例如，先前需要在多個模組中進行多次呼叫和錯誤處理的複雜資料處理例程被封裝如下：
class DataProcessingFacade:
def __init__(self):
self.extractor = DataExtractor()
self.transformer = DataTransformer()
self.loader = DataLoader()
def process_data(self, source):
data = self.extractor.extract(source)
data = self.transformer.transform(data)
return self.loader.load(data)
facade = DataProcessingFacade()
processed_data = facade.process_data("data_source_identifier")
內容解密：
- 物件建立邏輯的隔離：將物件建立邏輯集中到工廠類別中，提高了程式碼的可維護性和可擴充套件性。
- 工廠方法的應用：使用工廠方法封裝物件建立邏輯，使得後續可以輕易引入快取策略、日誌記錄或動態選擇模型等功能。
- 外觀模式的使用：外觀模式簡化了複雜子系統之間的互動，提供了一個統一的介面，使得客戶端程式碼更加簡潔和易於維護。
- 自動化測試的重要性：在重構過程中，自動化測試確保了程式碼變更的安全性和正確性。
透過上述重構實踐，該金融服務平台成功地減少了技術債，提高了系統的可擴充套件性和可維護性，為未來的發展奠定了堅實基礎。
