Fellipeutaka Leon Solid

SOLID Principles

Five principles for building software that is easy to understand, extend, and maintain. They reduce coupling, increase cohesion, and make code testable.

When to Apply

Reference these principles when:

• Designing new classes, modules, or interfaces
• Refactoring code with too many responsibilities
• Reviewing PRs for architectural concerns
• Breaking apart god objects or fat interfaces
• Deciding where to draw module boundaries
• Making code more testable

Quick Reference

See references/PRINCIPLES.md for detailed explanations and TypeScript examples.

Detection Checklist

Ask these questions for every class and module:

Applying SOLID at Different Scales

Relationships Between Principles

• SRP + ISP: Splitting responsibilities often means splitting interfaces too
• OCP + DIP: Depending on abstractions is what makes extension without modification possible
• LSP + OCP: If subtypes are substitutable, you can extend behavior by adding new subtypes
• DIP + ISP: Small focused interfaces make dependency inversion practical

Common Anti-Patterns

Best Practices

DO

• Start with SRP — it's the foundation for all others
• Use interfaces to define boundaries between components
• Let violations emerge from real problems, then fix them
• Prefer composition over inheritance for extending behavior
• Keep interfaces small and role-specific
• Inject dependencies through constructors

DON'T

• Apply SOLID dogmatically to trivial code (a 5-line utility doesn't need an interface)
• Create abstractions before you have at least two implementations
• Confuse SRP with "single method" — it's about reasons to change, not size
• Force Liskov compliance on classes that shouldn't be in the same hierarchy
• Over-segregate interfaces into single-method fragments when a cohesive group makes sense

Converted and distributed by TomeVault — claim your Tome and manage your conversions.