Solid Principles
SOLID — five design principles for flexible, testable, resilient software
Tags
Overview
Purpose
SOLID — five design principles for flexible, testable, resilient software
Rules
SOPR-001: S - Single Responsibility: A module should have one, and only one, reason to change
Martin Clean Architecture Ch.7 — "A module should be responsible to one, and only one, actor." SRP is about limiting the impact of change — when a requirement changes, only one module needs modification.
Verification: Code review
SOPR-002: O - Open-Closed: Software entities should be open for extension, closed for modification
Martin Clean Architecture Ch.8 — originally Bertrand Meyer (1988). New behavior should be added by writing new code, not by modifying existing working code. Achieved through polymorphism and interfaces.
Verification: Code review
SOPR-003: L - Liskov Substitution: Subtypes must be substitutable for their base types without altering correctness
Martin Clean Architecture Ch.9 — Liskov/Wing 1994 formalization. If code works with type T, it must work with any subtype S of T. In Go: any implementation of an interface must honor the same behavioral contract.
Verification: Code review + contract tests
SOPR-004: I - Interface Segregation: Clients should not be forced to depend on methods they do not use
Martin Clean Architecture Ch.10 — "Depending on something that carries baggage you don't need can cause unexpected troubles." Go naturally encourages small interfaces (io.Reader = 1 method).
Verification: Code review
SOPR-005: D - Dependency Inversion: High-level modules should not depend on low-level modules. Both should depend on abstractions.
Martin Clean Architecture Ch.11 — "The most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions." Go interfaces are implicitly satisfied — no inheritance needed.
Verification: Code review