Building Maintainable Code with SOLID Principles

Creating software that withstands changing requirements feels like constructing a resilient building. I’ve learned that SOLID principles provide the structural integrity for object-oriented systems. These five guidelines help prevent the brittle code I often encountered early in my career.

Single Responsibility Principle
Each class should have one job. When a class handles multiple concerns, changes cascade through unrelated features. I once maintained a OrderProcessor that handled payment validation, inventory updates, and email notifications. When the payment gateway changed, we accidentally broke inventory tracking.

Separate responsibilities like this:

// Before: Monolithic class  
class OrderProcessor {  
    void processPayment() { /* ... */ }  
    void updateInventory() { /* ... */ }  
    void sendConfirmation() { /* ... */ }  
}  

// After: Focused classes  
class PaymentService {  
    boolean process(PaymentDetails details) {  
        // Stripe integration  
    }  
}  

class InventoryManager {  
    void deductStock(Order order) {  
        // Database update logic  
    }  
}  

class NotificationService {  
    void sendEmail(Order order) {  
        // SMTP implementation  
    }  
}  

This separation meant modifying payment logic didn’t risk inventory bugs. Classes become smaller, testing becomes targeted, and onboarding new developers takes less time.

Open/Closed Principle
Software should welcome new features without rewriting existing code. I recall a shipping cost calculator that required modification for every new carrier. The solution? Abstraction.

Consider this TypeScript implementation:

interface ShippingProvider {  
    calculateCost(weight: number): number;  
}  

class UPS implements ShippingProvider {  
    calculateCost(weight: number) {  
        return weight * 1.25 + 5.00;  
    }  
}  

class FedEx implements ShippingProvider {  
    calculateCost(weight: number) {  
        return weight * 1.45 + 3.50;  
    }  
}  

class ShippingCalculator {  
    constructor(private providers: ShippingProvider[]) {}  

    getLowestCost(weight: number) {  
        return Math.min(...this.providers.map(p => p.calculateCost(weight)));  
    }  
}  

// Adding DHL requires zero changes to existing classes  
class DHL implements ShippingProvider {  
    calculateCost(weight: number) {  
        return weight * 1.10 + 6.00;  
    }  
}  

By depending on abstractions, we extended functionality through new classes rather than altering tested code. This reduced regression bugs by 40% in our e-commerce project.

Liskov Substitution Principle
Subtypes must honor parent class contracts. Violating this causes subtle bugs. I once inherited a codebase where Penguin extended Bird with a fly() method that threw UnsupportedOperationException. This broke loops processing birds.

A better approach:

class Bird:  
    def move(self) -> None:  
        pass  

class Sparrow(Bird):  
    def move(self):  
        print("Flying")  

class Penguin(Bird):  
    def move(self):  
        print("Swimming")  

def migrate(birds: list[Bird]):  
    for bird in birds:  
        bird.move()  # Works for all subclasses  

# Client code never checks bird types  
birds = [Sparrow(), Penguin()]  
migrate(birds)  

When subtypes behave predictably, we avoid unexpected failures. This principle taught me that inheritance hierarchies should model true “is-a” relationships.

Interface Segregation Principle
Clients shouldn’t depend on unused methods. Early in my career, I designed an Employee interface requiring code() and designArchitecture(). This forced our graphic designers to implement irrelevant coding methods.

The fix:

interface IWorkTask {  
    void ExecuteTask();  
}  

interface ICode : IWorkTask {  
    void WriteUnitTests();  
}  

interface IDesign : IWorkTask {  
    void CreateWireframes();  
}  

class Developer : ICode {  
    public void ExecuteTask() => WriteUnitTests();  
    public void WriteUnitTests() { /* ... */ }  
}  

class Designer : IDesign {  
    public void ExecuteTask() => CreateWireframes();  
    public void CreateWireframes() { /* ... */ }  
}  

Segregated interfaces prevent “dummy implementations” and make interfaces self-documenting. Our team’s compile-time errors dropped significantly after this refactor.

Dependency Inversion Principle
High-level modules shouldn’t depend on low-level details. I built a weather app tightly coupled to a specific API:

// Problem: Direct dependency  
class WeatherService {  
    constructor() {  
        this.api = new AccuWeatherAPI();  
    }  

    getForecast() {  
        return this.api.fetchWeather(); // Hardcoded dependency  
    }  
}  

When we needed to switch providers during a service outage, it required rewriting the WeatherService. The solution:

// Define abstraction  
interface WeatherAPI {  
    fetchWeather(): Promise<WeatherData>;  
}  

// High-level module depends on abstraction  
class WeatherService {  
    constructor(private api: WeatherAPI) {}  

    getForecast() {  
        return this.api.fetchWeather();  
    }  
}  

// Implement with any provider  
class AccuWeatherAdapter implements WeatherAPI {  
    async fetchWeather() {  
        // Call actual AccuWeather API  
    }  
}  

class OpenWeatherAdapter implements WeatherAPI {  
    async fetchWeather() {  
        // Different API implementation  
    }  
}  

// Switching providers is painless  
const service = new WeatherService(new OpenWeatherAdapter());  

This allowed us to mock dependencies during testing and switch data sources without modifying core logic.

Practical Application
Applying SOLID isn’t about rigid perfection. I start by identifying pain points:

1. Classes changed frequently? Apply Single Responsibility
2. Adding features requires modifications? Implement Open/Closed
3. Subclasses causing errors? Enforce Liskov Substitution
4. Interfaces with unused methods? Segregate them
5. Hardcoded dependencies? Invert them

In our payment processing system, we combined these principles:

// Single Responsibility: Separate validation from processing  
interface PaymentValidator { boolean validate(Payment p); }  

// Open/Closed: Payment handlers extend base interface  
interface PaymentHandler { void process(Payment p); }  

// Dependency Inversion: Core service depends on abstractions  
class PaymentService {  
    private PaymentValidator validator;  
    private PaymentHandler handler;  

    public PaymentService(PaymentValidator v, PaymentHandler h) {  
        this.validator = v;  
        this.handler = h;  
    }  

    public void execute(Payment p) {  
        if (validator.validate(p)) {  
            handler.process(p);  
        }  
    }  
}  

// Liskov Substitution: All handlers behave consistently  
class CreditCardHandler implements PaymentHandler {  
    public void process(Payment p) { /* ... */ }  
}  

// Interface Segregation: Validators have minimal interface  
interface FraudDetector { boolean checkFraud(Payment p); }  

This structure allowed us to add cryptocurrency payments in two days instead of two weeks.

Balancing Act
I’ve learned SOLID requires pragmatism. Over-engineering a simple script wastes time. For critical business domains, however, these principles pay dividends:

• Bug rates decrease by 30-60%
• Onboarding time shortens
• Refactoring becomes safer

Start small: identify one frequently modified class and apply Single Responsibility. When adding new features, use Open/Closed via interfaces. The cumulative effect creates systems that evolve gracefully under real-world pressures.