SOLID Principles Rules

architectureoopbest-practices

Enforces the five SOLID object-oriented design principles across the codebase to ensure maintainable, extensible, and testable code regardless of language.

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

## SOLID Principles Rules ### S — Single Responsibility Principle - Every class, module, or function must have exactly one reason to change - A class that handles both persistence and business logic violates SRP — split them - If you cannot describe a class's purpose in one sentence without "and", it does too much - Service classes: one domain action (e.g., `UserRegistrationService`, not `UserService`) - When a file grows beyond 200 lines, evaluate whether it has multiple responsibilities - Side effects must be explicit and isolated — a function that computes and persists violates SRP ### O — Open/Closed Principle - Classes should be open for extension but closed for modification - Use strategy pattern, polymorphism, or composition to add behavior without editing existing code - Do not modify existing switch/if-else chains to add new cases — extract to polymorphism - Plugin architectures and dependency injection enable OCP: inject behavior, do not hardcode it - Use abstract base classes or interfaces to define extension points - New requirements should result in new files, not edits to stable core logic ### L — Liskov Substitution Principle - A subclass must be substitutable for its base class without altering the correctness of the program - A subtype must not throw exceptions the base type does not throw - A subtype must not strengthen preconditions (require more than the base) - A subtype must not weaken postconditions (guarantee less than the base) - If a derived class overrides a method and the caller must check the type, LSP is violated - Prefer composition over inheritance when you cannot guarantee substitutability - "Is-a" relationship must hold behaviorally, not just structurally ### I — Interface Segregation Principle - Clients should not be forced to depend on methods they do not use - Split fat interfaces into smaller, focused ones: `Readable`, `Writable`, `Closeable` not `FileManager` - A class implementing an interface should use all its methods — if not, split the interface - Prefer many small interfaces over one general-purpose interface - Mock objects in tests reveal ISP violations: if a mock needs to stub many irrelevant methods, the interface is too large ### D — Dependency Inversion Principle - High-level modules must not depend on low-level modules — both must depend on abstractions - Abstractions must not depend on details — details must depend on abstractions - Always inject dependencies via constructor parameters — do not instantiate concrete implementations inside classes - Define interfaces at the boundary where high-level policy meets low-level implementation - Application code depends on `IUserRepository` interface; infrastructure provides `PostgresUserRepository` - Inversion of control containers (DI frameworks) enforce DIP at the architecture level ### Applying SOLID Together - Code review checklist: Can you unit test this class with mocks? If not, DIP is likely violated - Code review checklist: Did adding a new feature require editing existing classes? If yes, OCP may be violated - Code review checklist: Does a derived class throw "UnsupportedOperationException"? LSP is violated - New feature workflow: define an interface first → write a test against the interface → implement the class - Refactoring trigger: more than one team edits the same class for different features → SRP violation - Avoid over-engineering: apply SOLID where change is likely, not uniformly everywhere ### Naming & Structure Signals - Classes named `[X]Manager`, `[X]Helper`, `[X]Processor` are SRP warnings — verify their scope - Interfaces with more than 5-7 methods are ISP warnings - Constructors that call `new ConcreteService()` are DIP violations - `if (obj instanceof SubType)` in client code is an LSP warning ### Anti-patterns - God classes that know and do everything — violate SRP, ISP, and DIP simultaneously - Inheritance chains deeper than 3 levels — likely LSP violations lurking - Hard-coded dependencies on specific file systems, databases, or HTTP clients — violates DIP - Interfaces added solely for testability without architectural purpose — add interfaces where the boundary is real

CLI

npx mindaxis apply solid-principles-rules --target cursor --scope project

Используется в паках

Clean Architecture

Principled code structure and design

Открыть пак →

Code Quality Ultimate

Ultimate code quality and review toolkit

Открыть пак →

DDD Toolkit

Model complex domains with confidence

Открыть пак →

Hexagonal Architecture

DDD, CQRS, and ports & adapters patterns

Открыть пак →

← Правила

SOLID Principles Rules

architectureoopbest-practices

Enforces the five SOLID object-oriented design principles across the codebase to ensure maintainable, extensible, and testable code regardless of language.

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

CLI

npx mindaxis apply solid-principles-rules --target cursor --scope project

Используется в паках

Clean Architecture

Principled code structure and design

Открыть пак →

Code Quality Ultimate

Ultimate code quality and review toolkit

Открыть пак →

DDD Toolkit

Model complex domains with confidence

Открыть пак →

Hexagonal Architecture

DDD, CQRS, and ports & adapters patterns

Открыть пак →