solid-principles

name	solid-principles
description	Use when: apply SOLID principles to make object-oriented code flexible and maintainable.

Goal: code whose responsibilities and dependencies are clear and stable.

Use for:

• reviewing class responsibilities and coupling
• guiding a refactor toward maintainable structure
• explaining why a design is hard to change

Workflow:

1. Single responsibility: one reason to change per unit.
2. Open/closed: extend behavior without modifying stable code.
3. Liskov: subtypes must honor the base type's contract.
4. Interface segregation: small interfaces over fat ones.
5. Dependency inversion: depend on abstractions, not details.
6. Apply only where it removes real pain.

Smells the principles address:

• god classes and shotgun surgery (SRP)
• modifying core code for every new case (OCP)
• subclasses that break expectations (LSP)
• clients forced to depend on unused methods (ISP)
• high-level code chained to low-level details (DIP)

Rules:

• principles are guidance, not dogma; avoid over-abstraction
• prefer the simplest design that stays changeable
• introduce abstraction at the second real use, not the first
• a clear, cohesive unit beats a clever hierarchy