Introduction

As a software developer, You have to write tons of lines of code and deal with very huge and complex projects. When dealing with complex projects, you have to focus on writing clean code that you and your teammates can easily understand.  Writing clean code also helps you to easily find the bugs and errors in your code. Writing clean code helps every programmer who works in a professional setting and cares for his work. It doesn’t matter if you write code for your side project, a startup or an enterprise, writing clean code has to be one of the biggest priorities when developing software.

So what exactly does clean code mean? It is debatable and totally depends on one’s perspective. But as a developer, we have to write codes that others can easily read and understand or sometimes helps us look at the code after a long time period. In short, we can say that writing clean code enhances the clarity of the program. Clean code gives you a consistent & readable codebase that helps you to write readable, understandable, maintainable and easy to test and debug code.

SOLID Principle

In order to write clean code, you have to use some coding principles and coding standards.

All of us who worked as software developers, At some point have heard, have experienced, had an idea, or have worked with SOLID principles. These principles have been long described and used in several programming languages. In case you have never heard about it, do not worry, this article is going to introduce a little about this acronym and its relationship with software development.

The letter “S” means Single Responsibility Principle, the letter “O” denotes Open-Closed Principle, “L” corresponds to the term Liskov Substitution Principle, “I” refers to the term Interface Segregation Principle, and finally the letter “D” is referring to Dependency Inversion Principle.

In this blog, we only discuss the Single Responsibility Principle and in the next blogs, we discuss other principles.

S → Single Responsibility Principle (SRP)

The Single Responsibility Principle (SRP) states that each software module or class should have one and only one reason to change, in other words, a class should have a single responsibility.

“Gather together the things that change for the same reasons. Separate those things that change for different reasons.”

— Bob Martin

But what is a responsibility and how do we know that the class has only one responsibility?  it can be considered as a role that a class is responsible for executing, but a better definition when talking about this principle would be that a responsibility basically is a reason for changing. This means that if it is possible to think of more than one reason to change a specific class, it is because this class is assuming more than one responsibility.

Problem with multiple responsibility

• Difficulty in understanding and maintenance of code.
• Difficulty of reuse. With responsibilities connected closely in the same class, it can be difficult to change one of these responsibilities without compromising others (rigidity) and may end up breaking other parts of the software (fragility).
• High coupling, i.e., the class has an excessive number of dependencies and therefore is more subject to changes due to changes in other classes (again the fragility)

We usually violate this principle because it is hard to apply this pattern in terms of the number of files, classes/and or protocols that we needed to create.

We can detect this problem easily considering that:

• A view controller can be a data source or delegate of your table view or collection view.
• You can make web requests in a view controller.
• You can use business logic in a view controller.
• You can format elements in a view controller.
• You can handle the navigation in a view controller.

we can understand it easily with an example

At a first look, this code looks perfectly fine. But this code breaks the single responsibility principle. There are different responsibilities that this class is trying to complete. That is a sign of bad design.

This class is handling so many responsibilities first it is trying to fetch data from API using the function fetchMoviesFromAPI() then parse it into another function parseResponse() and also displaying errors using displayFetchError() then filters the movie list to show just the upcoming movies, and finally reloads the table showing the cells, formatting the cell title and at the end displaying movie details on cell taping.

we can achieve the SRP by using Protocol, delegation and dividing the class into smaller parts at some places

So, first, we’ve isolated the view responsibilities to just display the information in the View using protocols (MovieListView), delegation (MovieListTableViewDataSource), and MVP pattern (MovieListPresenter). We’ve moved the table data source job, creating a class that handles all the table work needed and the table view selection through delegates (MovieListTableViewDataSource). We’ve created a MovieListPresenter where we can handle the business logic and fetch data from the API using the MoviesAPIClient class. We parse that response using MovieParseHandler.

Conclusion

This principle helps you to create clean code where every class or protocol has only one set of responsibilities, but it also increases the number of code lines and a bit of complexity. To apply these concepts, you also have a basic understanding of design/architectural patterns. But this helps you while testing, debugging and maintaining the code.