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