# Solid Principles

> Enforce SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) in object-oriented design. Use when writing or reviewing classes and modules.

- Skill: `majiayu000/solid-principles` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/solid-principles`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/solid-principles/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/solid-principles

---


# SOLID Principles Skill

You are assisting with code that must follow SOLID principles strictly.

## Principles to Enforce

### 1. Single Responsibility Principle (SRP)
- Each class should have ONE reason to change
- Each function should do ONE thing well
- Separate concerns: business logic, data access, presentation, validation
- If a class name contains "and" or "or", it likely violates SRP

**Red flags:**
- Classes with multiple unrelated methods
- Functions doing multiple operations
- Mixed concerns (e.g., validation + persistence in same method)

### 2. Open/Closed Principle (OCP)
- Open for extension, closed for modification
- Use abstract base classes and protocols for extensibility
- Prefer composition over inheritance
- New features should be added by extending, not modifying existing code

**Patterns to use:**
- Strategy pattern for varying algorithms
- Template method for varying steps
- Dependency injection for varying implementations

### 3. Liskov Substitution Principle (LSP)
- Subtypes must be substitutable for their base types
- Derived classes must not strengthen preconditions
- Derived classes must not weaken postconditions
- Avoid empty implementations or NotImplementedError in production code

**Guidelines:**
- Don't override methods to do nothing
- Maintain expected behavior contracts
- Use composition when inheritance doesn't fit naturally

### 4. Interface Segregation Principle (ISP)
- Clients should not depend on interfaces they don't use
- Create focused, cohesive protocols/abstract classes
- Many small interfaces > one large interface
- Use Python Protocols for implicit interfaces

**Implementation:**
- Split large interfaces into role-specific ones
- Use Protocol from typing module
- Avoid "fat" base classes with many optional methods

### 5. Dependency Inversion Principle (DIP)
- High-level modules should not depend on low-level modules
- Both should depend on abstractions (protocols, abstract classes)
- Abstractions should not depend on details
- Details should depend on abstractions

**Patterns:**
- Constructor injection for required dependencies
- Use abstract base classes or Protocols
- Depend on interfaces, not concrete implementations

## Code Review Checklist

When reviewing or writing code, check:
- [ ] Does each class have a single, clear responsibility?
- [ ] Can new behavior be added without modifying existing code?
- [ ] Can subclasses replace their parents without breaking functionality?
- [ ] Are interfaces focused and cohesive?
- [ ] Do modules depend on abstractions rather than concrete implementations?

## Practical Application for Admission Rules System

For the Norwegian admission rules system:
- **SRP**: Separate rule evaluation, grade calculation, quota management
- **OCP**: Make rules extensible (new admission rules without changing core engine)
- **LSP**: All rule types should be substitutable
- **ISP**: Separate interfaces for validators, calculators, reporters
- **DIP**: Depend on abstract rule interfaces, not concrete rule implementations

## Response Format

When applying SOLID principles:
1. Identify which principle(s) are relevant
2. Explain the violation if any exists
3. Provide refactored code following the principle(s)
4. Explain the benefit of the refactoring