Mastering SOLID: Real‑World Java Examples for Clean Code

1. Why Design Patterns?

Even without design patterns you can finish development, but patterns make code more readable, maintainable, and give you more time to relax. They are useful for complex, changing business logic that requires extensibility and adaptability, not for simple stable scenarios.

2. Open/Closed Principle

public class Seller {
    public BigDecimal sellCar(Car car) {
        return car.getPrice();
    }
}

Adding a discount directly to sellCar would affect all cars and break existing logic. Instead, create a subclass that extends the original class without modifying it.

public class DiscountCar extends Car {
    private BigDecimal price;
    private BigDecimal discount;
    @Override
    public BigDecimal getPrice() {
        return price.multiply(discount);
    }
}

3. Dependency Inversion Principle

public interface Any {
    String getName();
    BigDecimal getPrice();
}

public class Seller {
    public BigDecimal sell(Any any) {
        return any.getPrice();
    }
}

By depending on the abstract Any interface, the seller can handle any product (car, glass water, antifreeze, etc.) without being coupled to concrete classes.

4. Single Responsibility Principle

public class Seller implements Sing, Jump, Rap {
    public BigDecimal sell(Any any) {
        return any.doSell();
    }
    @Override
    public void sing() {
        System.out.println("seller sing");
    }
    @Override
    public void jump() {
        System.out.println("seller jumping");
    }
    @Override
    public void rap() {
        System.out.println("seller raping");
    }
}

Each skill (sing, jump, rap) is separated so that a seller can combine only the abilities it needs.

5. Law of Demeter

public class Boss {
    private Seller seller;
    private Report report;
    public void read() {
        seller.apply(report);
    }
}

This tightly couples Boss to Report. A better design lets the seller handle the report.

public class Boss {
    private Seller seller;
    public void read() {
        seller.apply();
    }
}

public class Seller {
    private Report report;
    public void apply() {
        report.show();
    }
}

This isolates responsibilities and reduces coupling, following the principle of least knowledge.

6. Interface Segregation Principle

Clients should depend only on the interfaces they actually use. Large, monolithic interfaces should be split into smaller, specific ones, as demonstrated with the separate Sing, Jump, and Rap interfaces.

7. Liskov Substitution Principle

Subtypes must be usable wherever their base type is expected without altering program behavior. Subclasses must fully implement parent behavior, may add their own features, and can widen input parameters or narrow output results while preserving correctness.

8. Composition over Inheritance Principle

Prefer composition or aggregation to reuse functionality; inheritance should be used only when it strictly follows the Liskov Substitution Principle. Composition works together with the Open/Closed principle to create flexible designs.

9. Summary

The seven SOLID principles—Open/Closed, Liskov Substitution, Dependency Inversion, Single Responsibility, Interface Segregation, Law of Demeter, and Composition over Inheritance—guide clean software architecture. Apply them according to business needs, but avoid letting the rules constrain practical development.