mcpField
P
python-design-patterns

python-design-patterns

github.com/full-stack-skills开发397 次安装5 周前更新
代码仓库

关于 python-design-patterns

面向创建组件或梳理复杂代码的 Python 设计指导技能。它强调简洁、职责清晰、组合优于继承及审慎抽象，以提升代码的可维护性和可测试性。

主要功能

  1. 01KISS 与单一职责原则
  2. 02关注点分离与分层
  3. 03组合优于继承
  4. 04判断抽象时机的指导
  5. 05提升可测试性的依赖注入

适用场景

  1. 01设计新的服务或组件
  2. 02重构庞大的类或函数
  3. 03在代码审查中评估耦合
  4. 04分离 I/O 与业务逻辑

安装

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

$npx skills add https://github.com/full-stack-skills/python-skills --skill python-design-patterns

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

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

LICENSE.txt
agents/
openai.yaml
examples/
advanced-usage.md
basic-usage.md
integration.md
references/
details.md

详细介绍

来源声明：本技能内容源自 wshobson/agents （MIT License, Copyright (c) 2024 Seth Hobson；完整许可文本见同目录 LICENSE.txt）。 使用、修改与再分发须遵守该 MIT 许可条款并保留版权声明。

中文描述

本技能提供全栈开发相关的最佳实践和模式指导。

name: python-design-patterns description: Python 设计模式，包括 KISS、关注点分离、单一职责以及组合优于继承。在从头设计新服务或组件并选择如何划分职责层次、重构不断膨胀的上帝类或单体函数、决定是新增抽象还是接受代码重复、评估拉取请求中紧耦合或内部类型泄漏等结构问题、为新的类层次结构选择继承还是组合，或代码库因 I/O 与业务逻辑纠缠而难以测试时，使用此技能。

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 的方法或简单的函数组合，看看是否比一串装饰器对象更清晰。

三次法则认为暂时不该抽象，但重复代码在某份副本更新而另一份未更新时会引发错误。 如果重复代码会以危险的方式产生偏差，就应该尽早抽象。三次法则是一种经验法则，而非铁律。如果这些副本已经出现错误分歧，就立即提取，并添加一个测试来验证共享行为。

服务层从 API 层导入内容，破坏了依赖方向。 这是违反分层架构的行为。服务层不得从处理器导入内容。引入一个共享类型／模型层，供两者导入，同时保持依赖箭头向下（API → Service → Repository）。

相关技能

  • python-testing-patterns — 使用此处建立的依赖注入结构，分别测试每一层。安装：npx skills add full-stack-skills/python-skills --skill python-testing-patterns。
  • python-project-setup — 设置项目结构和工具，从一开始就强制执行层边界。安装：npx skills add full-stack-skills/python-skills --skill python-project-setup。

能力边界

✅ 擅长处理
  • 全栈开发相关的最佳实践
  • 代码架构设计指导
  • 性能优化建议
⚠️ 需要素材
  • 具体的项目上下文
  • 技术栈信息
❌ 超出范围
  • 非技术领域的业务决策
  • 具体的代码实现（仅提供指导）

工作流程

步骤 1：需求分析

理解项目需求和技术约束

步骤 2：架构设计

设计系统架构和组件划分

步骤 3：实现指导

提供具体的实现建议和代码模式

步骤 4：代码审查

审查代码质量和最佳实践遵循情况

步骤 5：优化建议

提供性能优化和改进建议

常见问题

1. 过度设计

避免在简单场景中使用复杂的设计模式

2. 忽视性能

不要忽视性能优化，特别是在生产环境中

3. 安全考虑

始终考虑安全性和数据保护

4. 测试覆盖

确保有足够的测试覆盖，特别是边界情况

5. 文档维护

保持文档与代码同步更新

评论

支持 Markdown