設計模式怎麼用提示詞：按代碼場景推薦合適的設計模式（含不該用的情況和改造前後對比）
代碼裏 if-else 越堆越多、新增一種類型就要改好幾處，想知道該不該用、用哪種設計模式時用：貼上代碼和變化方向，AI 判斷問題本質，推薦最簡單的有效方案（不一定是設計模式），並給出改造前後的代碼對比。
通用大模型 對話模型通用
你是一名務實的資深工程師。你認為設計模式是解決特定問題的工具，而不是代碼質素的標誌；能用簡單函數解決的，就不要引入類層次結構。 - 語言：[語言]（例：Python、Java、TypeScript） - 代碼： [粘貼代碼] - 讓我難受的地方：[如每加一種支付方式都要改五處] - 預計未來的變化：[如半年內還要接入 3 種支付方式] 請回答： 1. 問題本質：這段代碼的「變化點」在哪裏，目前的結構為什麼讓變化變得困難。 2. 方案對比（2 到 3 個）：從最簡單的方案開始，例如： - 提取函數、用字典或映射表代替分支； - 合適的設計模式（如策略、工廠、模板方法、觀察者、責任鏈、適配器、裝飾器）； - 語言自身的特性（如一等函數、枚舉帶方法、接口）。 每個方案寫明：結構簡述、能解決什麼、引入了什麼成本。 3. 推薦：結合「預計未來的變化」選擇一個方案，說明為什麼。如果變化很少發生，可以明確建議「保持現狀，只做小的整理」。 4. 改造前後對比：給出改造後的完整代碼，說明新增一種類型時需要改動哪些地方（應該只有一處或很少幾處）。 5. 過度設計提醒：指出在這個場景下哪些模式看起來相關但不該用，以及為什麼。 6. 改造步驟：如何在不改變行為的前提下小步完成改造，每一步都可以運行測試。
高亮處換成你自己的內容：[語言]、[粘貼代碼]、[如每加一種支付方式都要改五處]、[如半年內還要接入 3 種支付方式]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[預計未來的變化] 是判斷要不要引入模式的關鍵依據。如果分支很多年才加一個，現在的 if-else 可能就是最好的寫法；如果下個季度要加三個，就值得把變化點抽出來。
常見坑：
- 為了「用上設計模式」而重構，一個簡單功能拆成五個類、三層接口，後來的人更難看懂。模板要求先給最簡單的方案。
- 在 Python、JavaScript 這類函數是一等公民的語言裏，很多經典模式（策略、命令）用一個函數字典就能實現，不需要照搬面向對象語言的寫法。
- 改造時順手改了行為。先確保有測試覆蓋，再小步改結構。
追問技巧：追問「如果一年後需求變成按地區選擇不同的支付方式組合，這個結構還能撐住嗎」，檢驗方案對未來變化的適應性。想學習時可以追問「用這段代碼講解策略模式和工廠模式的區別」。
示例輸出
示例，僅供參考（Python，按支付方式分支）
問題本質：變化點是「支付方式」，但每種方式的邏輯分散在 pay()、refund()、query() 三個函數的分支裏，新增一種要改三處。
推薦：每種支付方式實現同一組方法，用字典註冊。這是策略模式的輕量寫法，不需要工廠類。
python
from typing import Protocol
class PaymentChannel(Protocol):
def pay(self, order) -> str: ...
def refund(self, order, amount) -> None: ...
CHANNELS: dict[str, PaymentChannel] = {
"alipay": AlipayChannel(),
"card": CardChannel(),
}
def pay(order):
channel = CHANNELS.get(order.channel)
if channel is None:
raise ValueError(f"不支持的支付方式：{order.channel}")
return channel.pay(order)新增一種支付方式：新寫一個類，在 CHANNELS 中加一行。
不建議：抽象工廠、模板方法——目前各支付方式的流程差異很大，沒有可複用的公共骨架。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～