DEV Community: Muzammil

Understanding Code Smell

Muzammil — Thu, 29 May 2025 11:46:58 +0000

What is Code Smell?

Code smell refers to any symptom in the source code that may indicate a deeper problem.
While it may not immediately cause bugs, it points to weaknesses in the code's structure or design that could make the system harder to maintain, read, and extend in the future.

Why is Understanding Code Smell Importan?

Uderstanding code smells is essential because it helps us:

Maintain code quality.
Facilitate code maintenance and future development.
Reduce the chance of introducing bugs.
Avoid problems caused by poor design choices.
Build a professional portofolio as backend developer.

Here are some of the most common types of code smell, along with brief explanations and simple examples.

🔹 Duplicated Code

This happens when the same code appears in multiple places. it makes maintenance harder because if something change, you have to update it everywhere.
Example:

public int add(int a, int b) { 
    return a + b;
}

public int addThree(int a, int b, int c) { 
    return a + b + c; 
}

Solution: Combine the duplicated logic into one flexible method.

🔹 Long Method

A method that's too long and does too many things is hard to understand and test.
Example:

public void processOrder() {
    validateOrder();
    calculateDiscount();
    applyTax();
    generateInvoice();
    sendNotification();
}

Solution: Break it into smaller methods, each with a single, clear responsibility.

🔹 Feature Envy

This occurs when a method relies too much on another class's data or behavior.
Example:

public String getCustomerInfo(Customer customer) {
    return customer.getName() + ", " + customer.getAddress();
}

Solution: Move this logic to the relevant class (in this case, Customer).

🔹 Large Class

A class that has too many responsibilities can become hard to manage.
Example:

public class OrderManager {
    void createOrder() {}
    void cancelOrder() {}
    void calculateTotal() {}
    void sendNotification() {}
}

Solution: Split it into smaller classes, each handling one responsibility.

🔹 Primitive Obsession

Using primitive types (like String or int) instead of creating classes to represent complex concepts.
Example:

public class User {
    private String phoneNumber;
    private String email;
}

Solution: Create a ContactInfo class to encapsulate contact details.

🔹 Long Parameter List

A method that takes too many parameters can be confusing and hard to work with. It's easy to forget the correct order of the parameters, and it clutters the method signature.
Example:

public void createUser(String name, String email, String phone, String address, String city, String postalCode) {
    // logic
}

Solution: Group related parameters into a class or object, such as a UserProfile or ContactInfo.

Consolusion

Code smells are not bugs, but they signal that the code could be improved. By recognizing and addressing these semlls, you can write cleaner, more maintainable, and professional code.

Understanding Object Calisthenics: Writing Cleaner Code

Muzammil — Sat, 12 Oct 2024 14:13:34 +0000

In software development, adhering to clean code practices is essential to creating maintainable, scalable, and efficient applications. One approach that encourages this discipline is Object Calisthenics, a set of rules designed to guide developers in writing better object-oriented code.

In this post, I’ll explore the principles of Object Calisthenics and how they can be applied to write cleaner, more structured code. If you’re interested in diving deeper into practical code examples or learning how these principles are implemented in a real project, feel free to check out my GitHub repository for more details.

For a more hands-on explanation, visit my GitHub repository.

What is Object Calisthenics?

Object Calisthenics is a programming exercise consisting of nine rules that encourage you to adhere to object-oriented principles. The rules themselves were introduced by Jeff Bay in his book The ThoughtWorks Anthology. The aim is to encourage a deeper focus on the design and structure of your code by following these constraints.

Here are the 9 rules:

1. Only One Level of Indentation Per Method

This principle states that each method should have only one level of indentation. By keeping the level of indentation low, we can improve readability and make the code easier to maintain. If a method has too many levels of indentation, it’s often a sign that the logic inside is too complex and needs to be broken down into smaller pieces.

Example of Implementation
Here’s an example of a method that does not follow this principle:

public class OrderService {
    public void processOrder(Order order) {
        if (order.isValid()) {
            if (order.hasStock()) {
                if (order.hasEnoughBalance()) {
                    order.ship();
                } else {
                    System.out.println("Insufficient balance.");
                }
            } else {
                System.out.println("Stock unavailable.");
            }
        } else {
            System.out.println("Invalid order.");
        }
    }
}

In the code above, there are multiple levels of indentation in the processOrder method, which makes it harder to read, especially when the logic grows more complex.

Now, let’s look at how we can follow the principle by simplifying the logic:

public class OrderService {
    public void processOrder(Order order) {
        if (!isOrderValid(order)) return;
        if (!hasStock(order)) return;
        if (!hasEnoughBalance(order)) return;

        shipOrder(order);
    }

    private boolean isOrderValid(Order order) {
        if (!order.isValid()) {
            System.out.println("Invalid order.");
            return false;
        }
        return true;
    }

    private boolean hasStock(Order order) {
        if (!order.hasStock()) {
            System.out.println("Stock unavailable.");
            return false;
        }
        return true;
    }

    private boolean hasEnoughBalance(Order order) {
        if (!order.hasEnoughBalance()) {
            System.out.println("Insufficient balance.");
            return false;
        }
        return true;
    }

    private void shipOrder(Order order) {
        order.ship();
    }
}

This version has one level of indentation per logic block, making the code cleaner and easier to maintain.

2. Don’t Use the `else` Keyword

n object-oriented programming, the use of the else keyword often leads to cluttered and hard-to-maintain code. Instead of relying on else statements, you can structure your code using early returns or polymorphism. This approach enhances readability, reduces complexity, and makes your code more maintainable.

Let's first look at an example that uses the else keyword:

public class Order {
    public void processOrder(boolean hasStock, boolean isPaid) {
        if (hasStock && isPaid) {
            System.out.println("Order processed.");
        } else {
            System.out.println("Order cannot be processed.");
        }
    }
}

In this example, the else statement forces us to handle the negative case explicitly, adding additional complexity. Now, let's refactor this to avoid using else:

public class Order {
    public void processOrder(boolean hasStock, boolean isPaid) {
        if (!hasStock) {
            System.out.println("Order cannot be processed: out of stock.");
            return;
        }

        if (!isPaid) {
            System.out.println("Order cannot be processed: payment pending.");
            return;
        }

        System.out.println("Order processed.");
    }
}

By eliminating else, you write code that is more focused, with each section handling a single responsibility. This aligns with the "Single Responsibility Principle" and helps create cleaner, more maintainable software.

3. Wrap All Primitives and Strings

One of the key practices in Object Calisthenics is to wrap all primitives and strings in custom classes. This rule encourages developers to avoid using raw primitive types or strings directly in their code. Instead, they should encapsulate them within meaningful objects. This approach leads to code that is more expressive, easier to understand, and can grow in complexity without becoming unmanageable.

Let's consider an example where we use primitive types and strings directly:

public class Order {
    private int quantity;
    private double pricePerUnit;
    private String productName;

    public Order(int quantity, double pricePerUnit, String productName) {
        this.quantity = quantity;
        this.pricePerUnit = pricePerUnit;
        this.productName = productName;
    }

    public double calculateTotal() {
        return quantity * pricePerUnit;
    }
}

In this code, int, double, and String are used directly. While this might seem simple, it doesn't express the intent of each value clearly and makes it harder to introduce new behaviors or constraints specific to those values later.

Now, let’s refactor this code to wrap the primitives and strings:

public class Quantity {
    private final int value;

    public Quantity(int value) {
        if (value < 1) {
            throw new IllegalArgumentException("Quantity must be greater than zero.");
        }
        this.value = value;
    }

    public int getValue() {
        return value;
    }
}

public class Price {
    private final double value;

    public Price(double value) {
        if (value <= 0) {
            throw new IllegalArgumentException("Price must be positive.");
        }
        this.value = value;
    }

    public double getValue() {
        return value;
    }
}

public class ProductName {
    private final String name;

    public ProductName(String name) {
        if (name == null || name.isEmpty()) {
            throw new IllegalArgumentException("Product name cannot be empty.");
        }
        this.name = name;
    }

    public String getValue() {
        return name;
    }
}

public class Order {
    private final Quantity quantity;
    private final Price pricePerUnit;
    private final ProductName productName;

    public Order(Quantity quantity, Price pricePerUnit, ProductName productName) {
        this.quantity = quantity;
        this.pricePerUnit = pricePerUnit;
        this.productName = productName;
    }

    public double calculateTotal() {
        return quantity.getValue() * pricePerUnit.getValue();
    }
}

Key Changes:

Meaningful Classes, Instead of using raw int, double, and String, we created Quantity, Price, and ProductName classes. This gives meaning to each of these values and allows for custom validation or additional behavior.
Enhanced Validation, We added validation to ensure that Quantity and Price always have valid values, such as non-negative amounts. This is much easier to manage when primitives are wrapped in their own classes.
Improved Readability, The code is more self-explanatory. You no longer need to guess what a particular primitive value represents. Each value is encapsulated in a class that conveys its meaning clearly.

4. First-Class Collections

Whenever you use a collection like a List or Map, make it a dedicated object. This keeps your code clean and ensures that the logic related to the collection is encapsulated.

Problem: Using a Raw Collection Directly

public class Order {
    private List<String> items;

    public Order() {
        this.items = new ArrayList<>();
    }

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

    public List<String> getItems() {
        return items;
    }
}

In this example, Order directly uses a List<String> to manage its items. This design can lead to code that lacks clear meaning and responsibilities. It also allows external classes to manipulate the list freely, leading to potential misuse.

Solution: Using a First-Class Collection

public class Order {
    private Items items;

    public Order() {
        this.items = new Items();
    }

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

    public List<String> getItems() {
        return items.getAll();
    }
}

class Items {
    private List<String> items;

    public Items() {
        this.items = new ArrayList<>();
    }

    public void add(String item) {
        items.add(item);
    }

    public List<String> getAll() {
        return new ArrayList<>(items); // Return a copy to prevent external modification
    }

    public int size() {
        return items.size();
    }
}

Explanation:

First-Class Collection, The Items class is a wrapper around the List<String>. This pattern gives the collection its own class and behavior, making it easier to manage and encapsulate rules. For example, you can easily add validation or methods that operate on the list (e.g., size()).
This makes the code more meaningful and prevents misuse of raw collections, as external classes don't have direct access to the list.

Benefits of First-Class Collections:

Encapsulation: Collection logic is kept in one place.
Maintainability: Any changes to how the collection is handled can be done in the Items class.
Readability: Code that deals with collections is clearer and more meaningful.

6. One Dot Per Line

One Dot Per Line is an Object Calisthenics rule that encourages developers to avoid chaining multiple method calls on a single line. The principle focuses on readability, maintainability, and debugging ease by ensuring that each line in the code only contains a single method call (represented by one "dot").

The Problem with Method Chaining (Multiple Dots Per Line)
When multiple methods are chained together on one line, it can become difficult to:

Read: The longer the chain of method calls, the harder it is to understand what the code does.
Debug: If something breaks, it’s not clear which part of the chain failed.
Maintain: Changing a specific operation in a long chain can affect other parts of the code, leading to harder refactoring.

Example: Multiple Dots Per Line (Anti-Pattern)

public class OrderProcessor {
    public void process(Order order) {
        String city = order.getCustomer().getAddress().getCity().toUpperCase();
    }
}

In this example, we have multiple method calls chained together (getCustomer(), getAddress(), getCity(), toUpperCase()). This makes the line of code compact but harder to understand and maintain.

Solution: One Dot Per Line
By breaking down the method chain, we make the code easier to read and debug:

public class OrderProcessor {
    public void process(Order order) {
        Customer customer = order.getCustomer();  // One dot: getCustomer()
        Address address = customer.getAddress();  // One dot: getAddress()
        String city = address.getCity();          // One dot: getCity()
        String upperCaseCity = city.toUpperCase(); // One dot: toUpperCase()
    }
}

This code follows the One Dot Per Line rule by breaking down a method chain into smaller, readable pieces, ensuring that each line performs only one action. This approach increases readability, making it clear what each step does, and improves maintainability by making future changes easier to implement. Moreover, this method helps during debugging, since each operation is isolated and can be checked independently if any errors occur.

In short, the code emphasizes clarity, separation of concerns, and ease of future modifications, which are key benefits of applying Object Calisthenics rules such as One Dot Per Line.

6. Don’t Abbreviate

One of the key rules in Object Calisthenics is Don’t Abbreviate, which emphasizes clarity and maintainability by avoiding cryptic or shortened variable names. When we name variables, methods, or classes, it’s important to use full, descriptive names that accurately convey their purpose.

Example of Bad Practice (With Abbreviations):

public class EmpMgr {
    public void calcSal(Emp emp) {
        double sal = emp.getSal();
        // Salary calculation logic
    }
}

EmpMgr is unclear; is it Employee Manager or something else?
calcSal is not obvious at a glance—what kind of salary calculation does it perform?
emp and sal are vague and can confuse developers reading the code later.

Example of Good Practice (Without Abbreviations):

public class EmployeeManager {
    public void calculateSalary(Employee employee) {
        double salary = employee.getSalary();
        // Salary calculation logic
    }
}

EmployeeManager makes it clear that this class is managing employees.
calculateSalary is explicit, showing the method’s purpose.
employee and salary are self-explanatory and much more readable.

By avoiding abbreviations, we make our code more understandable and maintainable, especially for other developers (or even ourselves) who will work on it in the future.

7. Keep Entities Small

In Object Calisthenics, one of the fundamental rules is Keep Entities Small, which encourages us to break down large classes or methods into smaller, more manageable ones. Each entity (class, method, etc.) should ideally have one responsibility, making it easier to understand, maintain, and extend.

Example of Bad Practice (Large Class with Multiple Responsibilities):

public class Employee {
    private String name;
    private String address;
    private String department;

    public void updateAddress(String newAddress) {
        this.address = newAddress;
    }

    public void promote(String newDepartment) {
        this.department = newDepartment;
    }

    public void generatePaySlip() {
        // Logic for generating a payslip
    }

    public void calculateTaxes() {
        // Logic for calculating taxes
    }
}

In this example, the Employee class is doing too much. It’s handling address updates, promotions, payslip generation, and tax calculation. This makes the class harder to manage and violates the Single Responsibility Principle.

Example of Good Practice (Small Entities with Single Responsibilities):

public class Employee {
    private String name;
    private String address;
    private String department;

    public void updateAddress(String newAddress) {
        this.address = newAddress;
    }

    public void promote(String newDepartment) {
        this.department = newDepartment;
    }
}

public class PaySlipGenerator {
    public void generate(Employee employee) {
        // Logic for generating a payslip for an employee
    }
}

public class TaxCalculator {
    public double calculate(Employee employee) {
        // Logic for calculating taxes for an employee
        return 0.0;
    }
}

By breaking the class into smaller entities, we:

Keep the Employee class focused on core employee information.
Extract responsibilities like payslip generation and tax calculation into their own classes (PaySlipGenerator and TaxCalculator).

8. No Getters/Setters/Properties

The principle of avoiding getters and setters encourages encapsulation by ensuring that classes manage their own data and behavior. Instead of exposing internal state, we should focus on providing meaningful methods that perform actions relevant to the class's responsibility.

Consider the following example that uses getters and setters:

public class BankAccount {
    private double balance;

    public double getBalance() {
        return balance;
    }

    public void setBalance(double balance) {
        this.balance = balance;
    }

    public void deposit(double amount) {
        balance += amount;
    }

    public void withdraw(double amount) {
        if (amount <= balance) {
            balance -= amount;
        }
    }
}

In this example, the getBalance method exposes the internal state of the BankAccount class, allowing direct access to the balance variable.

A better approach would be to avoid exposing the balance directly and provide methods that represent the actions that can be performed on the account:

public class BankAccount {
    private double balance;

    public void deposit(double amount) {
        balance += amount;
    }

    public void withdraw(double amount) {
        if (amount <= balance) {
            balance -= amount;
        }
    }

    public boolean hasSufficientFunds(double amount) {
        return amount <= balance;
    }
}

In this revised example, the BankAccount class no longer has getters or setters. Instead, it provides methods for depositing, withdrawing, and checking if there are sufficient funds. This approach maintains the integrity of the internal state and enforces rules about how the data can be manipulated, promoting better encapsulation and adherence to the single responsibility principle.

9. Separate UI from Business Logic

The principle of separating user interface (UI) code from business logic is essential for creating maintainable and testable applications. By keeping these concerns distinct, we can make changes to the UI without affecting the underlying business rules and vice versa.

Consider the following example where the UI and business logic are intertwined:

public class UserRegistration {
    public void registerUser(String username, String password) {
        // UI Logic: Validation
        if (username.isEmpty() || password.length() < 6) {
            System.out.println("Invalid username or password.");
            return;
        }

        // Business Logic: Registration
        System.out.println("User " + username + " registered successfully.");
    }
}

In this example, the registerUser method contains both UI logic (input validation) and business logic (registration). This makes the method harder to test and maintain.

A better approach is to separate the UI from the business logic, as shown in the following example:

public class UserRegistration {
    public void registerUser(User user) {
        // Business Logic: Registration
        System.out.println("User " + user.getUsername() + " registered successfully.");
    }
}

public class UserRegistrationController {
    private UserRegistration userRegistration;

    public UserRegistrationController(UserRegistration userRegistration) {
        this.userRegistration = userRegistration;
    }

    public void handleRegistration(String username, String password) {
        // UI Logic: Validation
        if (username.isEmpty() || password.length() < 6) {
            System.out.println("Invalid username or password.");
            return;
        }

        User user = new User(username, password);
        userRegistration.registerUser(user);
    }
}

class User {
    private String username;
    private String password;

    public User(String username, String password) {
        this.username = username;
        this.password = password;
    }

    public String getUsername() {
        return username;
    }
}

In this improved design, the UserRegistration class contains only the business logic for registering a user. The UserRegistrationController is responsible for handling UI logic, such as input validation and user interaction. This separation makes it easier to test and maintain the business logic without being affected by changes in the UI.

By adhering to this principle, we enhance the maintainability and testability of our applications, making them easier to adapt to future requirements.

Conclusion

Object Calisthenics might seem a bit strict at first, but give it a try! It's all about writing cleaner, more maintainable code that feels good to work with. So, why not challenge yourself? Start small, and before you know it, you’ll be crafting code that not only works but also shines. Happy coding!

SOLID Principles in object-oriented design

Muzammil — Mon, 16 Sep 2024 15:55:30 +0000

SOLID is an acronym that represents five design principles aimed at enhancing the understanding, flexibility, and maintainability of object-oriented designs. While these principles were initially applied to object-oriented design, they can also serve as a foundational philosophy for other methodologies, such as agile development or adaptive software development. By following SOLID principles, developers can create more modular, changeable, and error-resistant code.

Adapted from source: Wikipedia.

The SOLID principles are a set of five guidelines that help software developers create more understandable, flexible, and maintainable object-oriented systems. They were introduced by Robert C. Martin, also known as "Uncle Bob," and have since become a core foundation for writing clean and scalable code. Here are the 5 principles we’ll cover:

Single-responsibility Principle
Open-closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

Next, we will explore how to implement the SOLID principles and compare code before and after applying these principles.

Single Responsibility Principle (SRP)

The Single Responsibility Principle (SRP) is one of the five SOLID principles of object-oriented design and arguably one of the most fundamental. It states that a class should have only one reason to change, meaning it should have only one job or responsibility. This principle encourages the creation of classes that are focused and concise, making the system easier to understand, maintain, and extend.

Why SRP Matters ?
The core idea behind the Single Responsibility Principle (SRP) is to keep classes focused and cohesive. By ensuring that each class is responsible for just one aspect of the functionality, we can reduce its complexity. This approach offers several benefits:

Easier Maintenance: A class with a single responsibility is easier to understand and modify. Changes are less likely to inadvertently affect other parts of the system since the class has a clear and narrow focus.
Improved Reusability: When classes are designed to do one thing well, they become more versatile. You can reuse these focused classes in different parts of your application or even in entirely different projects.
Enhanced Testability: Testing becomes simpler with small, single-purpose classes. They have fewer dependencies and less complex behavior, making them easier to set up and verify.

Spotting SRP Violations
Sometimes, classes can become overburdened, trying to handle too many things at once. Here are a few signs that a class might be violating SRP:

Multiple Reasons to Change: If a class has more than one reason to change, it's likely taking on too many responsibilities.
Unrelated Methods or Properties: When a class contains methods or properties that aren't directly related to each other, it might be trying to do too much.
Vague or Overly Descriptive Names: If you need multiple words to describe what a class does (e.g., UserManager handling user data, authentication, and logging), it's a clue that the class might be violating SRP.

Example Without SRP
Let's consider a class that manages user data and also handles sending notifications:

public class User {
    private String name;
    private String email;

    // Methods to get and set user data
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }

    // Method to send an email notification
    public void sendEmailNotification(String message) {
        // Code to send an email
    }
}

In this example, the User class has two responsibilities:

Managing user data.
Sending email notifications.

If we need to change the way email notifications are sent, we have to modify the User class, which isn't related to managing user data.

Applying SRP
To adhere to SRP, we should split this class into two separate classes, each with a single responsibility:

public class User {
    private String name;
    private String email;

    // Methods to get and set user data
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }
}

public class EmailService {
    public void sendEmail(String emailAddress, String message) {
        // Code to send an email
    }
}

Now, the User class is solely responsible for managing user data, and the EmailService class handles sending email notifications. This separation makes the code more maintainable and testable.

When to Apply SRP
While SRP is a powerful principle, it's important not to take it to extremes. Over-separating responsibilities can lead to an excessive number of tiny classes, which might make the codebase harder to navigate. The goal is to find a balance where each class has a clear, single responsibility that makes sense within the context of the application.

Benefits of SRP

Reduced Complexity: Each class is smaller and more focused.
Better Organization: Classes are grouped logically based on their responsibilities.
Simpler Changes: Modifying one responsibility in the system is less likely to impact unrelated parts.
Improved Collaboration: Different team members can work on different aspects of the system without interfering with each other's work.

Open-Closed Principle (OCP)

The Open-Closed Principle (OCP) is the second principle in the SOLID framework of object-oriented design. It states that a software module (such as a class, module, or function) should be "open for extension, but closed for modification." In simpler terms, this means that the behavior of a module can be extended without modifying its existing code. This principle aims to make the codebase more flexible, scalable, and resilient to changes.

Why is OCP Important?
The Open-Closed Principle (OCP) is crucial because it allows software to adapt and evolve without risking the stability of existing, well-tested code. When you follow OCP, you can introduce new features or tweak existing behavior without having to alter the core logic of a class or module. This results in several key benefits:

Reduced Risk of Bugs: By not modifying existing code, you significantly lower the risk of introducing new bugs or breaking existing functionality.
Easier Maintenance: When your code is designed with extension in mind, adding new features or making changes becomes much simpler and more intuitive.
Enhanced Flexibility: Systems that adhere to OCP are more flexible and can easily accommodate new requirements without major rewrites or restructuring.

How to Implement OCP
Implementing the Open-Closed Principle often involves using abstraction and polymorphism. Here are a few ways to do it effectively:

Abstract Classes and Interfaces: Start by defining abstract classes or interfaces that outline general behaviors. Then, create concrete implementations that extend or implement these abstractions. This allows you to add new functionality simply by adding new subclasses.
Composition Over Inheritance: Instead of always relying on inheritance to extend functionality, use composition. This means building new features by combining objects rather than altering existing classes.
Design Patterns: Many design patterns are designed to facilitate OCP, like Strategy, Decorator, and Factory patterns. These patterns provide well-established ways to make your code more extensible.

Example Without OCP
Let's consider a simple example where a Shape class calculates the area of different shapes. Here's how it might look without adhering to OCP:

public class Shape {
    public enum ShapeType { CIRCLE, RECTANGLE }

    private ShapeType shapeType;
    private double radius;
    private double width;
    private double height;

    public Shape(ShapeType shapeType) {
        this.shapeType = shapeType;
    }

    public double calculateArea() {
        switch (shapeType) {
            case CIRCLE:
                return Math.PI * radius * radius;
            case RECTANGLE:
                return width * height;
            default:
                throw new IllegalArgumentException("Unknown shape type");
        }
    }

    // Getters and setters for radius, width, and height
}

In this example, if you need to add a new shape (e.g., a triangle), you have to modify the Shape class. This violates OCP because the class isn't closed for modification.

Applying OCP
To adhere to the Open-Closed Principle, we can refactor this code to use an abstract class or interface:

public abstract class Shape {
    public abstract double calculateArea();
}

public class Circle extends Shape {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

public class Rectangle extends Shape {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    @Override
    public double calculateArea() {
        return width * height;
    }
}

With this refactoring:

The Shape class is now open for extension. You can add new shapes (e.g., Triangle, Square) by creating new subclasses that implement the calculateArea method.
The Shape class is closed for modification. You don't need to modify existing classes to add new shapes.

Benefits of OCP

Scalability: Easily add new features without changing existing code, making the software more scalable.
Maintainability: By reducing the need to alter existing code, you lower the risk of introducing bugs and make the codebase more maintainable.
Reusability: Abstract classes and interfaces encourage the reuse of code, as they define a contract that different classes can implement.

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle (LSP) is the third principle in the SOLID design principles and was introduced by computer scientist Barbara Liskov in 1987. The principle states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. In other words, if a class S is a subclass of T, then objects of type T should be replaceable with objects of type S without altering the desirable properties of the program, such as correctness and task completion.

Why LSP is Important
LSP is crucial for ensuring that a system remains flexible and maintainable. It ensures that a subclass can stand in for its superclass without causing unexpected behavior. Here are some key reasons why LSP is important:

Code Reliability: LSP ensures that derived classes extend the behavior of a base class without changing its fundamental behavior. This reliability makes your code more predictable and reduces bugs.
Ease of Maintenance: If subclasses can be used interchangeably with their base classes, it's easier to add new subclasses or modify existing ones without worrying about breaking the system.
Improved Reusability: Proper adherence to LSP allows classes to be more reusable since they can be swapped with other classes without side effects.

Understanding LSP
To understand LSP better, consider the following points:

Behavioral Substitutability: Subclasses should be substitutable for their base classes. This means that a subclass should be able to fulfill the expectations of its superclass without altering its core functionality.
Method Consistency: Subclasses should override methods in a way that doesn't violate the expectations of the superclass. This includes not throwing unexpected exceptions or altering return values in a way that would be unexpected to the users of the superclass.
No Strengthened Preconditions: A subclass should not strengthen the preconditions of a method. In other words, it shouldn't require more specific conditions than the superclass method.
No Weakened Postconditions: Conversely, a subclass should not weaken the postconditions of a method. It should fulfill at least the same guarantees as the superclass method.

Example Without LSP
Let's look at an example that violates LSP. Consider a base class Rectangle and a derived class Square:

public class Rectangle {
    private int width;
    private int height;

    public void setWidth(int width) {
        this.width = width;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int getArea() {
        return width * height;
    }
}

public class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width);
    }

    @Override
    public void setHeight(int height) {
        super.setWidth(height);
        super.setHeight(height);
    }
}

At first glance, it might seem logical for Square to extend Rectangle, but this actually violates LSP. If we replace Rectangle with Square, the behavior of the setWidth and setHeight methods changes. Here's why:

public static void resize(Rectangle rect) {
    rect.setWidth(5);
    rect.setHeight(10);
    assert(rect.getArea() == 50); // This fails for Square
}

Applying LSP Correctly
To adhere to LSP, we need to design the classes so that the subclass can stand in for the superclass without altering the expected behavior. In this case, a Square isn't really a type of Rectangle because it has different constraints. Instead, they should both inherit from a more general shape class or interface:

public abstract class Shape {
    public abstract double area();
}

public class Rectangle extends Shape {
    private double width;
    private double height;

    public Rectangle(double width, double height){
        this.width = width;
        this.height = height;
    }

    public double getWidth(){
        return this.width;
    }

    public void setWidth(double width){
        this.width = width;
    }

    public double getHeight(){
        return this.height;
    }

    public void setHeight(double height){
        this.height = height;
    }

    @Override
    public double area() {
        return  this.width * this.height;
    }

}

public class Square extends Rectangle {

    public Square(double side){
        super(side, side);
    }

    @Override
    public void setWidth(double width){
        super.setWidth(width);
        super.setHeight(width);
    }

    @Override
    public void setHeight(double height){
        super.setHeight(height);
        super.setWidth(height);
    }

}

Now, both Rectangle and Square can be used interchangeably without violating LSP because they share a common interface that defines the behavior we expect.

Benefits of LSP

Consistency: Ensures consistent behavior across base and derived classes.
Robust Code: Reduces bugs and unexpected behavior by maintaining the integrity of class hierarchies.
Flexible Design: Makes your code more flexible and reusable by allowing polymorphism without side effects.

Interface Segregation Principle (ISP)

The Interface Segregation Principle (ISP) is the fourth principle in the SOLID design principles. It suggests that a client should not be forced to implement interfaces they don't use. In simpler terms, it's better to have many small, specific interfaces rather than a large, general-purpose one. This principle promotes creating more granular and focused interfaces that are tailored to the specific needs of clients.

Why ISP Matters
The Interface Segregation Principle plays a key role in building systems that are both adaptable and maintainable. By adhering to ISP, you can significantly enhance the quality of your codebase. Here's how ISP makes a difference:

Simplified Code: Focused interfaces ensure that classes only need to implement the methods they actually require. This reduces complexity and makes the code more understandable.
Greater Flexibility: When interfaces are smaller and more specialized, you can modify or extend parts of the system without unintended side effects on unrelated components.
Improved Maintainability: When changes occur, having specific contracts in the form of small interfaces ensures that modifications in one area of the system don't cascade into unrelated areas, making the system easier to maintain.
Reduced Side Effects: Large interfaces often force classes to include unnecessary methods, which can lead to unexpected behavior and increase the complexity of testing. ISP helps prevent this by promoting minimal and focused interfaces.

Understanding ISP in Practice
To effectively apply ISP, keep the following in mind:

Focus on Granularity: Design interfaces with specific client needs in mind. If an interface is too broad, encompassing multiple responsibilities, it's a sign that it should be split into smaller, more focused interfaces.
Separation of Concerns: Each interface should encapsulate a distinct set of responsibilities. This ensures that a class only interacts with the parts of an interface that are relevant to its functionality.
Avoid "Fat" Interfaces: A "fat" interface is one that has too many methods, many of which might not be relevant to all implementing classes. Instead, aim for "skinny" interfaces that expose only the necessary functionality.

Example Without ISP
Let's look at an example that violates ISP. Consider an interface Printer that has multiple methods for different types of printing devices:

public interface Printer {
    void print(Document document);
    void scan(Document document);
    void fax(Document document);
    void printDuplex(Document document);
}

Now, if we have a SimplePrinter class that only supports printing, it still has to implement all methods of the Printer interface:

public class SimplePrinter implements Printer {
    @Override
    public void print(Document document) {
        // Implementation for printing
    }

    @Override
    public void scan(Document document) {
        throw new UnsupportedOperationException("Scan not supported");
    }

    @Override
    public void fax(Document document) {
        throw new UnsupportedOperationException("Fax not supported");
    }

    @Override
    public void printDuplex(Document document) {
        throw new UnsupportedOperationException("Duplex printing not supported");
    }
}

In this example, SimplePrinter is forced to implement methods it doesn't support, which leads to the use of UnsupportedOperationException. This is a clear violation of ISP as SimplePrinter should not be forced to implement functionalities it doesn't need.

Applying ISP Correctly
To adhere to ISP, we should split the Printer interface into smaller, more specific interfaces:

public interface Printer {
    void print(Document document);
}

public interface Scanner {
    void scan(Document document);
}

public interface Fax {
    void fax(Document document);
}

public interface DuplexPrinter {
    void printDuplex(Document document);
}

Now, the SimplePrinter class only implements the Printer interface, avoiding unnecessary methods:

public class SimplePrinter implements Printer {
    @Override
    public void print(Document document) {
        // Implementation for printing
    }
}

If we have a more advanced device, like a MultiFunctionPrinter, it can implement multiple interfaces:

public class MultiFunctionPrinter implements Printer, Scanner, Fax, DuplexPrinter {
    @Override
    public void print(Document document) {
        // Implementation for printing
    }

    @Override
    public void scan(Document document) {
        // Implementation for scanning
    }

    @Override
    public void fax(Document document) {
        // Implementation for faxing
    }

    @Override
    public void printDuplex(Document document) {
        // Implementation for duplex printing
    }
}

This way, each class only implements the methods it actually needs, adhering to ISP.

Benefits of ISP

High Cohesion: By splitting interfaces into smaller, related groups of methods, we ensure high cohesion within the interfaces.
Low Coupling: Classes are only coupled to the interfaces they actually use, which reduces dependencies and increases modularity.
Easier Refactoring: Since interfaces are more focused, changing one part of the system is less likely to affect other parts.
Enhanced Reusability: Small, specific interfaces are more reusable and can be easily combined in different classes.

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle (DIP) is the fifth and final principle in the SOLID design principles. It addresses the issue of tight coupling between different modules in a system, promoting a design that is more flexible, testable, and scalable. According to DIP, high-level modules should not depend on low-level modules. Instead, both should depend on abstractions. Furthermore, these abstractions should not depend on details, but the details should depend on abstractions.

Breaking Down the Dependency Inversion Principle (DIP)
DIP might sound a bit technical at first, but its core idea is simple and powerful. Let's break it down:

High-Level Modules: Think of these as the strategic part of your application—the ones that make crucial decisions and drive the main logic.
Low-Level Modules: These are the operational parts, handling the specifics like database access, file management, or network communication.
Abstractions: Here’s the bridge between the two. Abstractions are like contracts (interfaces or abstract classes) that define how the high-level and low-level modules interact. They ensure that high-level modules aren't directly tied to the specifics of low-level implementations.

Why Should You Care About DIP?
DIP is more than just a fancy principle; it's a key player in making your codebase more robust and adaptable. Here’s why it's worth implementing:

Reduced Coupling: When high-level modules depend on abstractions instead of concrete implementations, the system becomes more flexible. This means you can make changes or add features with less risk of breaking things.
Enhanced Testability: Abstractions make it easier to replace real components with mock objects during testing. This simplifies unit tests and makes them more reliable since you can isolate parts of your code.
Improved Maintainability: By decoupling high-level modules from the nitty-gritty details of low-level modules, you make it easier to maintain and update your code. For example, switching from one database to another won’t require a complete overhaul of your high-level logic.
Supports Dependency Injection: DIP goes hand-in-hand with dependency injection, a pattern where dependencies are injected into a class rather than hard-coded. This leads to more modular and loosely-coupled code.

Example Without DIP
Consider a UserService class that directly depends on a UserRepository class to fetch user data:

public class UserRepository {
    public User getUserById(int id) {
        // Code to fetch user from database
    }
}

public class UserService {
    private UserRepository userRepository;

    public UserService() {
        this.userRepository = new UserRepository();
    }

    public User getUser(int id) {
        return userRepository.getUserById(id);
    }
}

In this example, UserService directly depends on the concrete implementation of UserRepository. If we decide to change the way users are stored (e.g., switch from a database to an external API), we have to modify the UserService class, which is tightly coupled to UserRepository.

Refactoring to Apply DIP
To adhere to the Dependency Inversion Principle, we need to introduce an abstraction that both UserService and UserRepository will depend on:

Define an Interface (Abstraction)

public interface UserRepository {
    User getUserById(int id);
}

Implement the Interface

public class DatabaseUserRepository implements UserRepository {
    @Override
    public User getUserById(int id) {
        // Code to fetch user from database
    }
}

Modify UserService to Depend on the Abstraction

public class UserService {
    private UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public User getUser(int id) {
        return userRepository.getUserById(id);
    }
}

Using Dependency Injection Now, we can use dependency injection to provide the concrete implementation of UserRepository when creating a UserService instance:

UserRepository userRepository = new DatabaseUserRepository();
UserService userService = new UserService(userRepository);

By following DIP, UserService now depends on the UserRepository interface, not a specific implementation. This makes UserService more flexible and easier to modify or test.

Benefits of DIP

Flexibility: High-level modules are not tightly bound to low-level modules, making it easier to change or extend functionality.
Scalability: Adding new features or changing implementations becomes more manageable without altering the core business logic.
Testability: By depending on abstractions, it's easier to use mock implementations in unit tests, resulting in more reliable and isolated testing.

For more details, you can check out the full code on my solid principle.