mcpField
P
python-design-patterns

python-design-patterns

github.com/wshobson开发41.9k23.1k 次安装2 周前更新
代码仓库

关于 python-design-patterns

帮助在 Python 组件和系统中运用基础设计原则的技能，面向希望让代码更简单、模块化、易测试且便于修改的开发者。

主要功能

  1. 01应用单一职责原则
  2. 02优先组合而非继承
  3. 03依据三次原则决定抽象
  4. 04通过依赖注入提升可测试性

适用场景

  1. 01设计新的 Python 组件
  2. 02重构复杂代码
  3. 03评估复杂度与耦合
  4. 04规划模块化架构

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/wshobson/agents --skill python-design-patterns

安装后在 Claude Code 中输入/python-design-patterns确认已加载。

附带文件references/details.md

详细介绍

Python 设计模式

使用基本设计原则编写可维护的 Python 代码。这些模式可帮助你构建易于理解、测试和修改的系统。

何时使用此技能

  • 设计新组件或服务
  • 重构复杂或混乱的代码
  • 决定是否创建抽象
  • 在继承与组合之间做出选择
  • 评估代码复杂度和耦合度
  • 规划模块化架构

核心概念

1. KISS（保持简单）

选择能起作用的最简单解决方案。复杂度必须由具体需求来证明其合理性。

2. 单一职责（SRP）

每个单元应只有一个变更原因。将关注点分离为职责聚焦的组件。

3. 组合优于继承

通过组合对象来构建行为，而不是扩展类。

4. 三次法则

在有三个实例之前不要抽象。重复往往比过早抽象更好。

快速开始

# Simple beats clever
# Instead of a factory/registry pattern:
FORMATTERS = {"json": JsonFormatter, "csv": CsvFormatter}

def get_formatter(name: str) -> Formatter:
    return FORMATTERS[name]()

详细模式与完整示例

详细的模式文档位于 references/details.md。当上述导航层级不够用时，请阅读该文件。

最佳实践总结

  1. 保持简单 - 选择能起作用的最简单解决方案
  2. 单一职责 - 每个单元只有一个变更原因
  3. 分离关注点 - 具有明确用途的不同层次
  4. 组合，而非继承 - 组合对象以获得灵活性
  5. 三次法则 - 抽象之前先等待
  6. 保持函数小巧 - 20-50 行（因复杂度而异），单一用途
  7. 注入依赖 - 使用构造函数注入以提高可测试性
  8. 先删除再抽象 - 移除死代码，然后再考虑模式
  9. 测试每一层 - 为每个关注点编写隔离测试
  10. 显式优于聪明 - 可读的代码胜过优雅的代码

故障排除

一个类不断膨胀，似乎承担了多项职责，但拆分它又感觉不对。 应用“变更原因”测试：列出所有可能需要修改此类的变更。如果列表中的条目来自不同领域（例如，HTTP 解析、业务规则和格式化），则拆分它。如果所有变更都源于同一领域关注点，则该类的规模可能是合适的。

通过构造函数注入所有依赖导致构造函数有 7 个以上参数。 这是一个类中职责过多的迹象，而不是依赖注入的问题。首先将该类拆分为更小的单元，然后每个构造函数自然会变小。

组合产生了难以追踪的深层嵌套包装对象。 保持组合浅层（2-3 层）。如果包装是唯一机制，考虑基于 Protocol 的方法或简单的函数组合是否比一连串装饰器对象更清晰。

三次法则说还不要抽象，但当更新一个副本而没有更新另一个时，重复导致了 bug。 以危险方式分叉的重复应尽早抽象。三次法则是一种启发式方法，而不是定律。如果副本已经出现错误的分叉，立即提取并添加一个测试来验证共享行为。

服务层正在从 API 层导入，破坏了依赖方向。 这是分层违规。服务层不得从处理器导入。引入一个共享的类型/模型层，让两者都可以从中导入，保持依赖箭头向下（API → 服务 → 仓库）。

相关技能

评论

支持 Markdown