陌讯skills聚合平台

design-patterns

📁 ratacat/claude-skills 📅 Jan 19, 2026
27
总安装量
21
周安装量
#13438
全站排名
安装命令
npx skills add https://github.com/ratacat/claude-skills --skill design-patterns

Agent 安装分布

claude-code 16
gemini-cli 13
opencode 13
codex 12
antigravity 10
github-copilot 9

Skill 文档

Design Patterns

Overview

Design patterns are proven solutions to recurring software design problems. They provide a shared vocabulary for discussing design and capture collective wisdom refined through decades of real-world use.

Core Philosophy: Patterns are templates you adapt to your context, not blueprints to copy. Use the right pattern when it genuinely simplifies your design—not to impress or over-engineer.

Foundational Principles

These principles underpin all good design:

Principle Meaning Violation Symptom
Encapsulate What Varies Isolate changing parts from stable parts Changes ripple through codebase
Program to Interfaces Depend on abstractions, not concretions Can’t swap implementations
Composition Over Inheritance Build behavior by composing objects Deep rigid class hierarchies
Loose Coupling Minimize interdependency between objects Can’t change one thing without breaking another
Open-Closed Open for extension, closed for modification Must edit existing code for new features
Single Responsibility One reason to change per class Classes doing too many things
Dependency Inversion High-level modules don’t depend on low-level Business logic coupled to infrastructure

Pattern Selection Guide

By Problem Type

CREATING OBJECTS
├── Complex/conditional creation ──────────→ Factory Method
├── Families of related objects ───────────→ Abstract Factory
├── Step-by-step construction ─────────────→ Builder
├── Clone existing objects ────────────────→ Prototype
└── Single instance needed ────────────────→ Singleton (use sparingly!)

STRUCTURING/COMPOSING OBJECTS
├── Incompatible interface ────────────────→ Adapter
├── Simplify complex subsystem ────────────→ Facade
├── Tree/hierarchy structure ──────────────→ Composite
├── Add behavior dynamically ──────────────→ Decorator
└── Control access to object ──────────────→ Proxy

MANAGING COMMUNICATION/BEHAVIOR
├── One-to-many notification ──────────────→ Observer
├── Encapsulate requests as objects ───────→ Command
├── Behavior varies by internal state ─────→ State
├── Swap algorithms at runtime ────────────→ Strategy
├── Algorithm skeleton with hooks ─────────→ Template Method
├── Reduce N-to-N communication ───────────→ Mediator
└── Sequential handlers ───────────────────→ Chain of Responsibility

MANAGING DATA ACCESS
├── Abstract data source ──────────────────→ Repository
├── Track changes for atomic commit ───────→ Unit of Work
├── Ensure object identity ────────────────→ Identity Map
├── Defer expensive loading ───────────────→ Lazy Load
├── Map objects to database ───────────────→ Data Mapper
└── Shape data for transfer ───────────────→ DTO

By Symptom

Symptom Consider
Giant switch/if-else on type Strategy, State, or polymorphism
Duplicate code across classes Template Method, Strategy
Need to notify many objects of changes Observer
Complex object creation logic Factory, Builder
Adding features bloats class Decorator
Third-party API doesn’t fit your code Adapter
Too many dependencies between components Mediator, Facade
Can’t test without database/network Repository, Dependency Injection
Need undo/redo Command
Object behavior depends on state State
Request needs processing by multiple handlers Chain of Responsibility

Domain Logic: Transaction Script vs Domain Model

Factor Transaction Script Domain Model
Logic complexity Simple (< 500 lines) Complex, many rules
Business rules Few, straightforward Many, interacting
Operations CRUD-heavy Rich behavior
Team/timeline Small team, quick delivery Long-term maintenance
Testing Integration tests Unit tests on domain

Rule of thumb: Start with Transaction Script. Refactor to Domain Model when procedural code becomes hard to maintain.

Quick Reference

Tier 1: Essential Patterns (Master First)

Pattern One-Line When to Use Reference
Strategy Encapsulate interchangeable algorithms Multiple ways to do something, swap at runtime strategy.md
Observer Notify dependents of state changes Event systems, reactive updates observer.md
Factory Encapsulate object creation Complex/conditional instantiation factory.md
Decorator Add behavior dynamically Extend without inheritance decorator.md
Command Encapsulate requests as objects Undo/redo, queuing, logging command.md

Tier 2: Structural Patterns

Pattern One-Line When to Use Reference
Adapter Convert interfaces Integrate incompatible code adapter.md
Facade Simplify complex subsystems Hide complexity behind simple API facade.md
Composite Uniform tree structures Part-whole hierarchies composite.md
Proxy Control access to objects Lazy load, access control, caching proxy.md

Tier 3: Enterprise/Architectural Patterns

Pattern One-Line When to Use Reference
Repository Collection-like data access Decouple domain from data layer repository.md
Unit of Work Coordinate atomic changes Transaction management unit-of-work.md
Service Layer Orchestrate business operations Define application boundary service-layer.md
DTO Shape data for transfer API contracts, prevent over-exposure dto.md

Additional Important Patterns

Pattern One-Line When to Use Reference
Builder Step-by-step object construction Complex objects, fluent APIs builder.md
State Behavior changes with state State machines, workflow state.md
Template Method Algorithm skeleton with hooks Framework extension points template-method.md
Chain of Responsibility Pass request along handlers Middleware, pipelines chain-of-responsibility.md
Mediator Centralize complex communication Reduce component coupling mediator.md
Lazy Load Defer expensive loading Performance, large object graphs lazy-load.md
Identity Map Ensure object identity ORM, prevent duplicates identity-map.md

Common Mistakes

Mistake Symptom Fix
Pattern Overuse Simple operations require navigating many classes Only use when solving real problem
Wrong Pattern Code feels forced, awkward Re-examine actual problem
Inheritance Abuse Deep hierarchies, fragile base class Favor composition (Strategy, Decorator)
Singleton Abuse Global state, hidden dependencies, hard to test Use dependency injection instead
Premature Abstraction Interfaces with single implementation Wait for real need to vary

Anti-Patterns to Recognize

  • God Object: One class does everything → Split using SRP
  • Anemic Domain Model: Objects are just data bags → Move behavior to objects
  • Golden Hammer: Same pattern everywhere → Match pattern to problem
  • Lava Flow: Dead code nobody removes → Delete it, VCS has your back

Modern Variations

Modern Pattern Based On Description
Dependency Injection Strategy + Factory Container creates and injects dependencies
Middleware Decorator + Chain of Responsibility Request/response pipeline
Event Sourcing Command Store state changes as events
CQRS Command/Query separation Separate read/write models
Hooks (React/Vue) Observer + Strategy Functional lifecycle subscriptions

Implementation Checklist

Before implementing a pattern:

  • Pattern solves a real problem in this codebase
  • Considered simpler alternatives
  • Trade-offs acceptable for this context
  • Team understands the pattern
  • Won’t over-engineer the solution
GitHub 仓库 ↗ ← 返回陌讯 Skills 聚合平台
本页面由 陌讯 Skills 聚合平台 收录整理，数据定期更新。