python-design-patterns
Apply Python Design Patterns
Write maintainable Python code using proven design patterns like KISS, Single Responsibility, and Composition over Inheritance to build systems that are easy to understand, test, and modify.
Download the skill ZIP
Upload in Claude
Go to Settings → Capabilities → Skills → Upload skill
Toggle on and start using
Test it
Using "python-design-patterns". Show me how to refactor a class that handles user registration, sends emails, logs activity, and saves to database
Expected outcome:
A refactored example splitting into UserService (business logic), UserRepository (data access), EmailNotifier (notifications), and ActivityLogger (logging) - each with single responsibility.
Using "python-design-patterns". I need to add payment processing to my order system. Should I inherit from a base Order class or use composition?
Expected outcome:
Explanation of why composition is preferred - you can swap payment providers, test with fakes, and avoid inheritance hierarchies. Example showing PaymentProcessor injected into OrderService.
Using "python-design-patterns". I have three similar functions that process data slightly differently. Should I create an abstraction?
Expected outcome:
Apply Rule of Three - wait until you see a clear pattern emerge. Show example of when duplication is better than wrong abstraction, and when to abstract.
Security Audit
SafeAll 35 static findings are false positives. The skill is a documentation file containing Python code examples for educational purposes. Python dictionary syntax was misidentified as shell backticks, email examples as network calls, and code examples as cryptographic algorithms or reconnaissance. No actual security risks present.
Quality Score
What You Can Build
Architecting new Python services
When starting a new service, use these patterns to create a clean, maintainable architecture from the beginning.
Refactoring tangled code
When faced with complex, coupled code, apply SRP and Separation of Concerns to untangle dependencies.
Evaluating abstraction decisions
When deciding whether to create an abstraction, use the Rule of Three to avoid premature generalization.
Try These Prompts
I need to solve [describe problem]. What is the simplest solution that works? Show me an example.
Here is my class [paste code] that does multiple things. How can I split it into classes with single responsibilities?
I have a base class with shared behavior and want to extend it. How can I use composition instead of inheritance? Show an example.
How should I organize [describe your application] into layers? Show me the separation of concerns with example code.
Best Practices
- Start with the simplest solution and add complexity only when justified by concrete requirements
- Keep functions focused to 20-50 lines with a single purpose
- Separate I/O operations from business logic into different layers
- Inject dependencies through constructors for testability
Avoid
- Creating abstractions too early before understanding the domain
- Using inheritance for code reuse instead of composition
- Mixing concerns like HTTP handling, validation, and database access in one class
- Making code clever instead of readable