SOLID Principles

What is SOLID?

SOLID is five design principles for keeping object-oriented code changeable without breaking things that shouldn't be affected. Each principle targets a specific, recurring way software gets harder to change over time — not five arbitrary rules, but five different failure modes a codebase actually runs into.

S — Single Responsibility Principle

"A class should have only one reason to change." A reason to change means a distinct stakeholder or concern that could independently trigger an edit — the business rule for validating an order, the schema of the orders table, the wording of a confirmation email. Bundling them means a change to one can accidentally break another.

Violation

// BAD — one class, four unrelated reasons to change
public class OrderManager {
    public void createOrder(Order order) {
        if (order.getItems().isEmpty()) {
            throw new ValidationException("Order must have items");
        }

        Connection conn = DriverManager.getConnection(url);
        PreparedStatement stmt = conn.prepareStatement(sql);
        stmt.executeUpdate();

        Transport.send(confirmationMessage);   // raw email sending, inline

        new FileWriter("orders.log").write("Order created: " + order.getId());
    }
}
// A change to the email template, the persistence library, or the log
// format all require editing the exact same method.

Correct Implementation

public class OrderValidator {
    public void validate(Order order) {
        if (order.getItems().isEmpty()) {
            throw new ValidationException("Order must have items");
        }
    }
}

public class OrderRepository {
    public void save(Order order) { /* persistence only */ }
}

public class NotificationService {
    public void sendOrderConfirmation(Order order) { /* email only */ }
}

public class OrderService {
    private final OrderValidator validator;
    private final OrderRepository repository;
    private final NotificationService notifications;

    public OrderService(OrderValidator validator, OrderRepository repository,
                        NotificationService notifications) {
        this.validator = validator;
        this.repository = repository;
        this.notifications = notifications;
    }

    public void createOrder(Order order) {
        validator.validate(order);
        repository.save(order);
        notifications.sendOrderConfirmation(order);
    }
}

O — Open/Closed Principle

"Open for extension, closed for modification." Add new behavior by adding new code, not by editing code that already works and is already tested.

Violation

// BAD — every new payment method means editing this method again
public class PaymentProcessor {
    public void processPayment(String type, BigDecimal amount) {
        if (type.equals("credit_card")) { /* ... */ }
        else if (type.equals("paypal")) { /* ... */ }
        // adding "crypto" means modifying this method, and re-testing
        // every branch above it all over again
    }
}

Correct Implementation

public interface PaymentMethod {
    boolean supports(PaymentType type);
    PaymentResult process(BigDecimal amount);
}

@Component
public class CreditCardPayment implements PaymentMethod { /* ... */ }

@Component
public class CryptoPayment implements PaymentMethod {
    // Adding this is the ENTIRE change — no existing class touched
}

@Service
public class PaymentProcessor {
    private final List<PaymentMethod> methods;

    // Spring injects every bean implementing PaymentMethod automatically —
    // registering a new strategy requires zero changes here
    public PaymentProcessor(List<PaymentMethod> methods) {
        this.methods = methods;
    }

    public PaymentResult process(PaymentType type, BigDecimal amount) {
        return methods.stream()
                .filter(m -> m.supports(type))
                .findFirst()
                .orElseThrow(() -> new UnsupportedPaymentTypeException(type))
                .process(amount);
    }
}

This is OCP as Spring developers actually apply it day to day — not just polymorphism in the abstract, but a collection of auto-discovered strategy beans the container assembles for you.

L — Liskov Substitution Principle

"Subtypes must be usable anywhere their base type is expected, without the caller needing to know the difference." More precisely (Design by Contract terms): a subtype may not strengthen preconditions or weaken postconditions the base type promised — it can only ask for less and guarantee at least as much.

Violation

// BAD — ShippedOrder can't honor Order's contract, it just throws instead
public class Order {
    private final List<OrderItem> items = new ArrayList<>();

    public void addItem(OrderItem item) {
        items.add(item);
    }
}

public class ShippedOrder extends Order {
    @Override
    public void addItem(OrderItem item) {
        throw new IllegalStateException("Cannot add items to a shipped order");
        // Any code written against Order — "call addItem(), it adds an item" —
        // now has to know about ShippedOrder specifically to avoid crashing.
        // The base type's contract is broken by this specific subtype.
    }
}

// This generic, perfectly reasonable code now has a hidden landmine:
void applyBackorderedItem(Order order, OrderItem item) {
    order.addItem(item);   // works for Order, throws for ShippedOrder — LSP violated
}

Correct Implementation

// GOOD — model the states that genuinely differ as distinct types,
// rather than one type that lies about what it can do
public interface Order {
    BigDecimal getTotal();
}

public interface MutableOrder extends Order {
    void addItem(OrderItem item);   // only types that can genuinely do this implement it
}

public class DraftOrder implements MutableOrder { /* addItem works normally */ }

public class ShippedOrder implements Order {
    // No addItem() here at all — the type system itself prevents calling
    // it on a shipped order, instead of a runtime exception discovering it
}

I — Interface Segregation Principle

"Clients shouldn't be forced to depend on methods they don't use." A large, general-purpose interface forces every implementer to either genuinely support every method, or fake support with a stub that throws.

Violation

// BAD — a read-only reporting client is forced to implement mutation methods it never calls
public interface OrderOperations {
    Order create(OrderRequest request);
    void cancel(Long orderId);
    void refund(Long orderId);
    byte[] generateInvoicePdf(Long orderId);
}

// A reporting dashboard only ever wants to READ order data,
// but this interface forces it to also implement mutation it will never use
public class ReportingOrderAdapter implements OrderOperations {
    @Override
    public void cancel(Long orderId) {
        throw new UnsupportedOperationException();   // forced stub
    }
    // ... and refund(), generateInvoicePdf() — same problem
}

Correct Implementation

public interface OrderCreator  { Order create(OrderRequest request); }
public interface OrderCanceller { void cancel(Long orderId); }
public interface OrderRefunder  { void refund(Long orderId); }
public interface InvoiceGenerator { byte[] generateInvoicePdf(Long orderId); }

// The reporting adapter now only depends on what it actually uses
public class ReportingOrderAdapter implements InvoiceGenerator {
    @Override
    public byte[] generateInvoicePdf(Long orderId) { /* ... */ }
}

// The full order service composes all four — it genuinely needs all of them
public class OrderService implements OrderCreator, OrderCanceller,
                                          OrderRefunder, InvoiceGenerator { /* ... */ }

D — Dependency Inversion Principle

"High-level modules and low-level modules should both depend on abstractions, not on each other directly." This is the principle Spring's dependency injection exists to apply automatically — the site's own convention of always using constructor injection is DIP put into practice, not a separate, unrelated style rule.

Violation

// BAD — OrderService is welded to one concrete persistence choice
public class MySQLOrderRepository {
    public void save(Order order) { /* MySQL-specific JDBC code */ }
}

public class OrderService {
    private MySQLOrderRepository repository = new MySQLOrderRepository();   // tight coupling

    public void createOrder(Order order) {
        repository.save(order);
        // Can't swap the database, and can't unit test this without a real one
    }
}

Correct Implementation

public interface OrderRepository {
    void save(Order order);
}

@Repository
public class JpaOrderRepository implements OrderRepository {
    @Override
    public void save(Order order) { /* JPA implementation */ }
}

@Service
public class OrderService {
    private final OrderRepository repository;   // depends on the abstraction

    // Constructor injection — Spring wires in whichever OrderRepository
    // bean exists, and this class never knows or cares which one
    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }
}

// Testing — swap in a mock with zero changes to OrderService itself
OrderRepository mockRepo = mock(OrderRepository.class);
OrderService testService = new OrderService(mockRepo);

When Applying SOLID Becomes the Problem It Was Meant to Solve

Every principle above has a real cost if applied where the underlying problem doesn't actually exist yet.

Similarly, Interface Segregation taken to an extreme produces an interface per method, forcing callers to depend on five tiny interfaces to do one coherent thing — segregate along real client boundaries (the reporting adapter genuinely only needs invoicing), not reflexively per method.

SOLID Quick Reference

Best Practices and Common Pitfalls

Interview Questions