Many of you will be familiar with SOLID as it is one of the fundamental design principles in object-oriented software development. The five principles that make up SOLID are as follows:

  • Single Responsibility Principle
  • Open/Closed Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Principle

All of these principles are worth getting familiar with, but in this blog, we will take a quick look at the first of them.

This grouping together of the five SOLID principles was done by legendary software engineer Rober C. Martin. And when talking about the Single Responsibility Principle, we can best introduce it with the words of the man himself:

“A class should have one, and only one, reason to change.”

The beauty is in the simplicity of the principle as stated, but it is a lot more complicated to put into practice. However, developers who do follow this principle will be those that produce some of the very best software. While often thought of as referring to classes alone, this principle can also be implemented in software components and microservices.

Why the Single Responsibility Principle is Good

Much like the simple summary of the principle itself, the Single Responsibility Principle is one that you should try to adhere to because it makes your life easier. By following the SRP, you protect yourself against some of the side effects that can be brought about by change in the future.

The Impact of Change

The SRP tries to simplify the impact that a change of requirements will have in the future. When requirements do change, this changes the responsibilities of each class. If your class has many responsibilities, this means that more changes will be needed. And even if only one responsibility changes, you need to change the whole class.

By only giving each class one responsibility, you counter the need for multiple changes when one requirement changes in the future. Basically, by following the one class, one responsibility principle, you reduce your workload and the need for multiple unnecessary and complicated changes that could bring unwanted side effects.

Easy Street

Aside from helping to negate the need for unnecessary changes, the SRP brings developers another significant benefit. Classes that only have one responsibility are simply easier to explain, implement, and understand than those designed to solve everything. The consequences of this simplicity are fewer bugs, faster development, and basically a much easier life in general.

However, one big thing to be aware of here is that you must resist the urge to make everything too simple. By taking the principle too far and creating classes that only have a single function, developers will encounter many problems later on when writing code. The SRP is a great guide, but you should not always extend it to all elements of your work.

The Caveat

The SRP can trick people into believing it is a simple, foolproof method to implement. It certainly is not.

When working on a long-term software build, the easiest option is usually to meet new requirements by adding a method of functionality to the existing code. This is quicker than writing a new class. Unfortunately, this is where classes will gain responsibilities that will make the software more challenging to maintain later on.

An excellent way to get around this problem is to ask yourself a quick question before going ahead with any changes: What is the responsibility of this class?

Suppose the answer that comes involves you needing to give an answer that includes “and”. In that case, there’s a good chance you are going against the Single Responsibility Principle. When this happens, it makes sense to look for a better way to implement the change.

In Conclusion

The SRP is one of the most popular design principles for a reason. It works really well when applied correctly.The problems occur when you decide to skip the principal and start to complicate classes with extra responsibilities.

By simply asking yourself “What is the responsibility of this class?” when preparing to make any changes, you can follow best practices and work in accordance with the SRP.

As long as you are careful not to take the SRP too far by creating classes with only one function, working to the Single Responsibility Principle will see you produce better work that is easier to explain and which is prone to less bugs and other issues in the future.

Stay up to date!

Subscribe to our newsletter

    Please prove you are human by selecting the Star.

    You may find interesting

    Post image
    Trading Analysis 05.05.2021
    How Can You Analyze the Market?

    Introduction Trading, the opportunity and the risk. All you have to do is to invest in a stock and wait for its value to rise. You can also invest in one of your favorite currencies and wait for t

    Daniel Fogel

    Read more
    Post image
    Software Development 04.30.2021
    The Single Responsibility Principle

    Many of you will be familiar with SOLID as it is one of the fundamental design principles in object-oriented software development. The five principles that make up SOLID are as follows: Single Res

    Michael Melnykov

    Read more
    Post image
    Active Trading 04.30.2021
    Why Active Trading is the Future

    The idea of a “passive income” has become a highly sought after, aspirational ideal, but most people don’t even realise what it means. Yes, it would be great to earn an additional “passive” income th

    Andreea Manea

    Read more