SOLID Principles

The SOLID principles are a set of five fundamental guidelines aimed at improving software quality and maintainability by promoting a clearer and more understandable design. Adopting these principles helps developers create systems that are easier to understand, change, and expand over time. The principles include:

1. S - Single Responsibility Principle (SRP): A class should have only one reason to change. This means that each class should be responsible for a single part of the software's functionality. By following this principle, you ensure that changes to a specific aspect of the system do not affect other parts, making code maintenance and evolution easier.

2. O - Open/Closed Principle (OCP): Software entities, such as classes and modules, should be open for extension but closed for modification. This implies that you should be able to add new behaviors to the system without changing existing code. This can be achieved through strategies like using interfaces and inheritance, allowing new functionalities to be added safely and in an organized manner.

3. L - Liskov Substitution Principle (LSP): Objects of a derived class should be able to replace objects of the base class without altering the expected behavior of the system. This means that when using a derived class, the system should continue to operate correctly as if it were using the base class. To respect this principle, it is important to design class hierarchies so that subclasses maintain the functionality and contracts defined by the base class.

4. I - Interface Segregation Principle (ISP): A class should not be forced to implement interfaces it does not use. This suggests that it is better to have several specific interfaces instead of a single, comprehensive one. This allows classes to implement only the interfaces they truly need, avoiding the implementation of unnecessary methods and promoting a more cohesive and less coupled design.

5. D - Dependency Inversion Principle (DIP): This principle states that classes should depend on abstractions, not on concrete classes. This promotes code flexibility and testability, as specific implementations can be changed or replaced without affecting the rest of the system. Dependency injection is a common technique to facilitate the application of this principle, allowing software components to be decoupled and managed more effectively.

Applying SOLID Principles in Spring Boot

1. Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change. This means a class should have a single responsibility or function.

Example:

// Order Service Class - Responsible only for order logic
@Service
public class OrderService {
    @Autowired
    private OrderRepository orderRepository;

    public void placeOrder(Order order) {
        // business logic to place an order
        orderRepository.save(order);
    }
}

// Notification Service Class - Responsible only for notification logic
@Service
public class NotificationService {
    public void sendOrderConfirmation(Order order) {
        // logic to send order confirmation
        System.out.println("Order confirmation sent to: " + order.getCustomer().getEmail());
    }
}

2. Open/Closed Principle (OCP)

Definition: Software entities should be open for extension but closed for modification. This can be achieved through interfaces and inheritance.

Example:

// Payment Interface
public interface PaymentMethod {
    void pay(double amount);
}

// Credit Card Payment Implementation
@Component
public class CreditCardPayment implements PaymentMethod {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " with credit card.");
    }
}

// PayPal Payment Implementation
@Component
public class PayPalPayment implements PaymentMethod {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " with PayPal.");
    }
}

// Payment Service Class
@Service
public class PaymentService {
    @Autowired
    private List<PaymentMethod> paymentMethods; // Injection of all implementations

    public void processPayment(PaymentMethod paymentMethod, double amount) {
        paymentMethod.pay(amount); // Calls the appropriate method
    }
}

3. Liskov Substitution Principle (LSP)

Definition: Objects of a derived class should be able to replace objects of the base class without altering the desired behavior.

Example:

// Base Notification Class
public abstract class Notification {
    public abstract void notifyUser(Order order);
}

// Email Notification
@Component
public class EmailNotification extends Notification {
    @Override
    public void notifyUser(Order order) {
        System.out.println("Sending email to: " + order.getCustomer().getEmail());
    }
}

// SMS Notification
@Component
public class SMSNotification extends Notification {
    @Override
    public void notifyUser(Order order) {
        System.out.println("Sending SMS to: " + order.getCustomer().getPhoneNumber());
    }
}

// Notification Service
@Service
public class NotificationService {
    @Autowired
    private List<Notification> notifications;

    public void notifyAll(Order order) {
        for (Notification notification : notifications) {
            notification.notifyUser(order);
        }
    }
}

4. Interface Segregation Principle (ISP)

Definition: A class should not be forced to implement interfaces it does not use. This means it is better to have several specific interfaces instead of a single, large one.

Example:

// Notification Interface
public interface Notifiable {
    void notifyUser(Order order);
}

// Payment Interface
public interface Payable {
    void pay(double amount);
}

// Notification Implementation
@Component
public class EmailNotification implements Notifiable {
    @Override
    public void notifyUser(Order order) {
        System.out.println("Sending email to: " + order.getCustomer().getEmail());
    }
}

// Payment Implementation
@Component
public class CreditCardPayment implements Payable {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " with credit card.");
    }
}

5. Dependency Inversion Principle (DIP)

Definition: Depend on abstractions, not on concrete classes. This means that high-level classes should not depend on low-level classes, but rather on abstractions.

Example:

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

// In-Memory Repository Implementation
@Repository
public class InMemoryOrderRepository implements OrderRepository {
    private List<Order> orders = new ArrayList<>();

    @Override
    public void save(Order order) {
        orders.add(order);
        System.out.println("Order saved in memory: " + order);
    }
}

// Service Implementation
@Service
public class OrderService {
    private final OrderRepository orderRepository;

    // Dependency Injection via constructor
    @Autowired
    public OrderService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    public void placeOrder(Order order) {
        orderRepository.save(order);
    }
}