Solid Principles – Single Responsibility Principle and Object-Oriented Design Basics

The SOLID design principles help us create maintainable, reusable, and flexible software designs. Each letter in the acronym SOLID stands for a specific principle.

Here is what each letter in the acronym stands for:

  • S: Single responsibility principle.
  • O: Open–closed principle.
  • L: Liskov substitution principle.
  • I: Interface segregation principle.
  • D: Dependency inversion principle.

In this article, our general focus will be on the Single Responsibility Principle. We will define this principle and look at some examples to help you understand how and why you should use it in your code.

The examples we will use in this article are going to be very basic. We will be using Java for our examples.

We’ll conclude this article by talking about the basics of object oriented design.

The Single Responsibility Principle (SRP)

The idea behind the SRP is that every class, module, or function in a program should have one responsibility/purpose in a program. As a commonly used definition, “every class should have only one reason to change”.

Consider the example below:

public class Student { public void registerStudent() { // some logic } public void calculate_Student_Results() { // some logic } public void sendEmail() { // some logic } }

The class above violates the single responsibility principle. Why?

This Student class has three responsibilities – registering students, calculating their results, and sending out emails to students.

The code above will work perfectly but will lead to some challenges. We cannot make this code reusable for other classes or objects. The class has a whole lot of logic interconnected that we would have a hard time fixing errors. And as the codebase grows, so does the logic, making it even harder to understand what is going on.

Imagine a new developer joining a team with this sort of logic with a codebase of about two thousand lines of code all congested into one class.

Now let’s fix this!

public class StudentRegister { public void registerStudent() { // some logic }
}
public class StudentResult { public void calculate_Student_Result() { // some logic }
}
public class StudentEmails { public void sendEmail() { // some logic }
}

Now we’ve separated each functionality in our program. We can call the classes anywhere we want to use them in our code.

The examples we used use just showed each class having one method – this is mainly for simplicity. You can have as many methods as you want but they should be linked to the responsibility of the class.

Now that we have separated the logic, our code is easier to understand as each core functionality has its own class. We can test for errors more efficiently.

The code is now reusable. Before, we could only use these functionalities inside one class but now they can be used in any class.

The code is also easily maintainable and scalable because instead of reading interconnected lines of code, we have separated concerns so we can focus on the features we want to work on.

What Is Object Oriented Design?

Object oriented design is a design methodology for building object-based systems and applications. This enables us to build systems with a collection of objects where each object has its own properties and methods.

Take the computer system as an example. Its hardware is made up of different parts that comprise the whole system.

Here are some of the general terms associated with object oriented design:

  • Objects: Each separate unit that makes up the system is an object. Objects can have properties and methods.
  • Classes: Classes act as a general description for objects. So an object is an instance of a class.
  • Encapsulation: this aids in bundling all the relevant data of an object in one unit. This also helps in restricting access to specific data and methods which should only be found in one object.
  • Inheritance: Inheritance makes it easier for us to extend the functionality of a class to other classes.  This way, we do not repeat the process of creating these functionalities over and over again.
  • Abstraction: This means showing only important attributes and hiding the irrelevant ones.
  • Polymorphism: This is the existence of an interface in various forms. The ability to extend an object/interface but with different or addition attributes.

Conclusion

In this article, we talked about the SOLID principles. Our main focus was on the Single Responsibility Principle (SRP).

We gave a definition for the SRP and saw two examples – one violating the principle and the other following the rules.

We also talked about the importance of the Single Responsibility Principle.

We concluded by looking at object oriented design and some of the terms that are associated with it.

Thank you for reading!

Posted by Contributor