solid

SOLID Principles

Before Applying

If .agents/stack-context.md exists, read it first. Apply this principle using idiomatic patterns for the detected stack. For framework-specific details, use context7 MCP or web search — don't guess.

Principle

Five design principles that produce modular, testable, and resilient systems. While originally framed for object-oriented design, the underlying ideas apply to any paradigm — functions, modules, services, or components.

Why This Matters in Production

SOLID code is change-friendly code. Production systems change constantly — new features, bug fixes, integrations, scaling. Systems designed with SOLID principles absorb change locally rather than requiring cascading modifications. This means fewer regressions, faster feature delivery, and smaller blast radius when things go wrong.

---

S — Single Responsibility Principle

A module should have one, and only one, reason to change.

Every module, function, or component should own exactly one piece of functionality. When a change request comes in, you should be able to predict which file needs editing without searching.

Violations look like:

• A function that validates input, queries the database, applies business logic, and formats the response
• A "utils" file that grows indefinitely because nothing else has a clear home
• A class that changes every time any feature in the system changes

Apply it:

• If a function does two things, split it into two functions
• If a module handles both "what to do" and "how to do it," separate policy from mechanism
• Name modules after their responsibility — if the name is vague ("Manager", "Helper", "Utils"), the responsibility is unclear

---

O — Open/Closed Principle

Software should be open for extension but closed for modification.

You should be able to add new behavior without modifying existing, working code. This doesn't mean you never touch existing code — it means you design so that the common extension points don't require it.