Design Principles in Java

SOLID Design Principles in Java

SOLID design principles are five object-oriented design guidelines used to create software that is easier to understand, extend, test, and maintain.

SOLID stands for:

Letter	Principle	Main Idea
S	Single Responsibility Principle	A class should have one responsibility
O	Open-Closed Principle	Extend behaviour without modifying existing code
L	Liskov Substitution Principle	Subclasses should safely replace their parent classes
I	Interface Segregation Principle	Classes should not implement methods they do not need
D	Dependency Inversion Principle	Depend on abstractions instead of concrete classes

These five principles are commonly associated with loose coupling and maintainable object-oriented design.

Solid design principle in Java

1. Single Responsibility Principle

The Single Responsibility Principle (SRP) states that a class should have one responsibility or one main reason to change.

A class that handles multiple unrelated tasks becomes difficult to test and maintain.

SRP Example

1// Responsible only for generating report data
2class Report {
3
4    // Generate and return the report content
5    String generate() {
6        return "Monthly Sales Report";
7    }
8}
9
10// Responsible only for printing reports
11class ReportPrinter {
12
13    // Print the generated report
14    void print(Report report) {
15        System.out.println(report.generate());
16    }
17}
18
19public class Main {
20    public static void main(String[] args) {
21
22        // Create the report and printer objects
23        Report report = new Report();
24        ReportPrinter printer = new ReportPrinter();
25
26        // Print the report
27        printer.print(report); // Output :- Monthly Sales Report
28    }
29}

Report generates the data, while ReportPrinter handles printing. Each class has a separate responsibility.

Single Responsibility Principle

2. Open-Closed Principle

The Open-Closed Principle (OCP) states that software components should be open for extension but closed for modification.

New functionality should be added by creating new classes rather than repeatedly changing tested code.

OCP Example

1// Abstraction for different discount rules
2interface Discount {
3
4    // Every discount must calculate a final price
5    double apply(double price);
6}
7
8// Regular customers receive a 10% discount
9class RegularDiscount implements Discount {
10
11    @Override
12    public double apply(double price) {
13        return price * 0.90;
14    }
15}
16
17// Premium customers receive a 20% discount
18class PremiumDiscount implements Discount {
19
20    @Override
21    public double apply(double price) {
22        return price * 0.80;
23    }
24}
25
26// Calculator works with any Discount implementation
27class PriceCalculator {
28
29    double calculate(double price, Discount discount) {
30        return discount.apply(price);
31    }
32}
33
34public class Main {
35    public static void main(String[] args) {
36
37        // Create the calculator
38        PriceCalculator calculator = new PriceCalculator();
39
40        // Use the regular discount implementation
41        System.out.println(
42                calculator.calculate(1000, new RegularDiscount())
43        ); // Output :- 900.0
44
45        // Use the premium discount implementation
46        System.out.println(
47                calculator.calculate(1000, new PremiumDiscount())
48        ); // Output :- 800.0
49    }
50}

A new discount can be added by creating another implementation. The existing PriceCalculator does not need to be modified.

Open-Closed Principle

3. Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that a child-class object should be usable wherever its parent type is expected without breaking the program’s expected behaviour.

Subclasses must respect the behaviour promised by the base class.

LSP Example

1// Base class defines a common movement operation
2abstract class Bird {
3
4    // Every bird must provide valid movement behaviour
5    abstract void move();
6}
7
8// Sparrow provides its appropriate movement
9class Sparrow extends Bird {
10
11    @Override
12    void move() {
13        System.out.println("Sparrow flies.");
14    }
15}
16
17// Penguin provides its appropriate movement
18class Penguin extends Bird {
19
20    @Override
21    void move() {
22        System.out.println("Penguin swims.");
23    }
24}
25
26public class Main {
27
28    // This method works with any valid Bird subclass
29    static void makeBirdMove(Bird bird) {
30        bird.move();
31    }
32
33    public static void main(String[] args) {
34
35        // Substitute Bird with Sparrow
36        makeBirdMove(new Sparrow()); // Output :- Sparrow flies.
37
38        // Substitute Bird with Penguin
39        makeBirdMove(new Penguin()); // Output :- Penguin swims.
40    }
41}

Both subclasses follow the Bird contract and can safely be passed to makeBirdMove().

Liskov Substitution Principle

4. Interface Segregation Principle

The Interface Segregation Principle (ISP) states that a class should not be forced to implement methods it does not need.

Instead of creating one large interface, create smaller interfaces for separate behaviours.

ISP Example

1// Interface only for printing behaviour
2interface Printable {
3    void print();
4}
5
6// Interface only for scanning behaviour
7interface Scannable {
8    void scan();
9}
10
11// BasicPrinter needs only printing behaviour
12class BasicPrinter implements Printable {
13
14    @Override
15    public void print() {
16        System.out.println("Printing document.");
17    }
18}
19
20// OfficeMachine supports both operations
21class OfficeMachine implements Printable, Scannable {
22
23    @Override
24    public void print() {
25        System.out.println("Office machine is printing.");
26    }
27
28    @Override
29    public void scan() {
30        System.out.println("Office machine is scanning.");
31    }
32}
33
34public class Main {
35    public static void main(String[] args) {
36
37        // BasicPrinter implements only what it needs
38        Printable printer = new BasicPrinter();
39        printer.print(); // Output :- Printing document.
40
41        // OfficeMachine implements both small interfaces
42        OfficeMachine machine = new OfficeMachine();
43        machine.scan(); // Output :- Office machine is scanning.
44    }
45}

BasicPrinter is not forced to implement a scanning method because printing and scanning use separate interfaces.

Interface Segregation Principle

5. Dependency Inversion Principle

The Dependency Inversion Principle (DIP) states that high-level classes should depend on abstractions instead of concrete implementations.

This reduces coupling and makes implementations easier to replace or test.

DIP Example

1// Abstraction for sending messages
2interface MessageSender {
3    void send(String message);
4}
5
6// Concrete email implementation
7class EmailSender implements MessageSender {
8
9    @Override
10    public void send(String message) {
11        System.out.println("Email sent: " + message);
12    }
13}
14
15// High-level class depends on the abstraction
16class NotificationService {
17
18    // Store the abstraction instead of a concrete sender
19    private final MessageSender sender;
20
21    // Receive the required implementation through the constructor
22    NotificationService(MessageSender sender) {
23        this.sender = sender;
24    }
25
26    // Send a notification through the supplied implementation
27    void notifyUser(String message) {
28        sender.send(message);
29    }
30}
31
32public class Main {
33    public static void main(String[] args) {
34
35        // Supply a concrete implementation of the abstraction
36        MessageSender sender = new EmailSender();
37
38        // NotificationService does not depend directly on EmailSender
39        NotificationService service =
40                new NotificationService(sender);
41
42        // Send the notification
43        service.notifyUser("Order shipped."); // Output :- Email sent: Order shipped.
44    }
45}

NotificationService depends on MessageSender, not directly on EmailSender. A different implementation, such as SmsSender, can be supplied without changing the service.

Dependency Inversion Principle

Benefits of SOLID Principles

Reduce tight coupling between classes
Make code easier to extend
Improve testability
Keep responsibilities organized
Support reusable components
Reduce the risk of changes breaking unrelated code

Summary

SOLID design principles improve object-oriented software design:

SRP ensures that classes have a single responsibility.
OCP allows functionality to be extended without modifying existing code.
LSP ensures that subclasses do not break base-class behaviour.
ISP prevents classes from implementing unnecessary methods.