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