SOLID Principles
Deep Knowledge: Use mcp__documentation__fetch_docs with technology: solid-principles for comprehensive documentation.
When NOT to Use This Skill
This skill focuses on OOP design principles. Do NOT use for:
- Functional programming - SOLID is primarily for OOP, use FP-specific patterns instead
- Simple scripts/utilities - SOLID adds complexity; use for larger systems
- Performance-critical code - Abstraction overhead may impact performance
- General code quality - Use
clean-code skill for naming, functions, readability
Anti-Patterns
| Anti-Pattern | Violated Principle | Solution |
|---|
| God Class | SRP | Split into focused classes with single responsibility |
| Switch on Type | OCP | Use polymorphism and strategy pattern |
| Throwing in Subclass | LSP | Ensure subclasses honor base class contract |
| Fat Interface | ISP | Split into smaller, role-specific interfaces |
| new Keyword Everywhere | DIP | Use dependency injection, depend on abstractions |
| Fragile Base Class | LSP, OCP | Prefer composition over inheritance |
| Marker Interface | ISP | Use proper abstractions with meaningful methods |
Quick Troubleshooting
| Issue | Principle | Fix |
|---|
| Class changing for multiple reasons | SRP | Extract separate classes for each responsibility |
| Must modify class to add feature | OCP | Make class extensible via interfaces/abstractions |
| Subclass breaks parent's tests | LSP | Ensure subclass can substitute parent without issues |
| Implementing empty methods | ISP | Split interface into smaller, focused interfaces |
| Hard to test due to concrete deps | DIP | Inject dependencies through interfaces |
| Can't swap implementations | DIP | Depend on abstractions, not concretions |
S - Single Responsibility
// ❌ Bad - Multiple responsibilities
class User {
save() { /* database logic */ }
sendEmail() { /* email logic */ }
generateReport() { /* report logic */ }
}
// ✅ Good - Single responsibility each
class User { /* user data only */ }
class UserRepository { save(user: User) { } }
class EmailService { send(to: string, message: string) { } }
class ReportGenerator { generate(user: User) { } }
O - Open/Closed
// ❌ Bad - Modify class to add new payment
class PaymentProcessor {
process(payment: Payment) {
if (payment.type === 'credit') { /* ... */ }
else if (payment.type === 'paypal') { /* ... */ }
// Must modify to add new type
}
}
// ✅ Good - Extend without modification
interface PaymentMethod {
process(amount: number): Promise<void>;
}
class CreditCardPayment implements PaymentMethod { }
class PayPalPayment implements PaymentMethod { }
class CryptoPayment implements PaymentMethod { } // New, no changes needed
L - Liskov Substitution
// ❌ Bad - Square can't substitute Rectangle
class Rectangle {
setWidth(w: number) { this.width = w; }
setHeight(h: number) { this.height = h; }
}
class Square extends Rectangle {
setWidth(w: number) { this.width = this.height = w; } // Breaks expectation
}
// ✅ Good - Use composition or separate abstractions
interface Shape {
getArea(): number;
}
class Rectangle implements Shape { }
class Square implements Shape { }
I - Interface Segregation
// ❌ Bad - Fat interface
interface Worker {
work(): void;
eat(): void;
sleep(): void;
}
class Robot implements Worker {
eat() { throw new Error('Robots dont eat'); } // Forced to implement
}
// ✅ Good - Segregated interfaces
interface Workable { work(): void; }
interface Eatable { eat(): void; }
interface Sleepable { sleep(): void; }
class Human implements Workable, Eatable, Sleepable { }
class Robot implements Workable { }
D - Dependency Inversion
// ❌ Bad - High-level depends on low-level
class UserService {
private db = new MySQLDatabase(); // Concrete dependency
}
// ✅ Good - Depend on abstractions
interface Database {
query(sql: string): Promise<any>;
}
class UserService {
constructor(private db: Database) { } // Injected abstraction
}
// Can use any implementation
new UserService(new MySQLDatabase());
new UserService(new PostgresDatabase());
new UserService(new MockDatabase()); // For testing
Authoritative Sources
Reference Documentation
