SOLID — From Zero To Potato

All of us are very familiar with the keywords ‘SOLID’ in our works and interview questions, so do we really understand about what is ‘SOLID’, if we want to be solid should know about the ‘SOLID’ in deep.

‘SOLID’ is the combination of 5 design principle in software development, these principle can help you in your daily life.Let me explain about what is ‘SOLID’ stand for :

1. Single Responsibility Principle (SRP): A class should have only one reason to change.
2. Open/Closed Principle (OCP): A class should be open for extension but closed for modification.
3. Liskov Substitution Principle (LSP): Subtypes should be substitutable for their base types
4. Interface Segregation Principle (ISP): A client should not be forced to depend on interfaces it does not use.
5. Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions.

Let me explain detail in terms of refactor in crab developer way

Single Responsibility Principle (SRP): Let’s say we have a Student class that not only stores information about the student, but also performs various operations related to the student, such as calculating their GPA, printing their report card, and sending emails to parents:

class Student(val name: String, val grades: List<Double>) {
    fun calculateGPA(): Double {
        // calculate the GPA based on the grades
    }

    fun printReportCard() {
        // print the report card for the student
    }

    fun sendEmailToParents() {
        // send an email to the parents of the student
    }
}

Before moving to the next, ask yourself how do you think about above example it is correctly written in terms of Single Responsibility Principle.

If you think the above example is fine and any problems, no worries you are not the one, i also thought like that before.In this example, the Student class is responsible for multiple tasks, violating the Single Responsibility Principle. This can make the class difficult to maintain and modify over time.

To adhere to the SRP, we can separate the responsibilities of the Student class by creating separate classes for each responsibility.For example, we can create a GPACalculator class that is responsible for calculating the GPA of a student, a ReportCardPrinter class that is responsible for printing the report card, and a EmailSender class that is responsible for sending emails to parents:

class Student(val name: String, val grades: List<Double>)

class GPACalculator(val student: Student) {
    fun calculateGPA(): Double {
        // calculate the GPA based on the grades of the student
    }
}

class ReportCardPrinter(val student: Student) {
    fun printReportCard() {
        // print the report card for the student
    }
}

class EmailSender(val student: Student) {
    fun sendEmailToParents() {
        // send an email to the parents of the student
    }
}

In this refactored version, each class has a single responsibility.The Student class is responsible for storing information about the student, while the GPACalculator, ReportCardPrinter, and EmailSender classes are responsible for specific operations related to the student.

This approach adheres to the Single Responsibility Principle because each class has a single responsibility, making the code easier to maintain and modify over time. Additionally, separating the responsibilities allows for greater flexibility in the future, such as the ability to swap out different implementations for each responsibility as needed.

Later I will explain about others principle with example and by doing refactor.Hope will be more understanding about Single Responsibility Principle (SRP) now.