设计模式怎么用提示词：按代码场景推荐合适的设计模式（含不该用的情况和改造前后对比）
代码里 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 条评论
还没有评论，来抢沙发～