Architecture & Design

Understanding SOLID Design Principles

One of the most innovative programming principles in recent years is named SOLID, an abbreviation for the first five object-oriented design principles. This particular principle was established by Robert C Martin and the main idea behind it is that you can use it to create easy, flexible, and extensible software. At its core, SOLID stands for the 5 principles listed below


Single Responsibility Principle

According to this principle, a class is only able to do a single job. If not, it ends up coupled. If you have changes to a class responsibility, other classes will also have responsibility changes, so this falls in line with everything. For example, you have a class that handles a list of superheroes or groceries. You can’t have the same class covering multiple things, so you need to create another class, which will make the experience better. You can use the Façade pattern if you want to better define classes.


Open-closed Principle

The basic concept around this principle is that any existing functions need to remain untouched when you create new features. You can extend entities if you want, however it’s not ok to change the classes in any way. For example, every item on the list can have a new logic added. The idea is to extend and avoid any modification. Instead, the trick is to create a class and then use the base class for an extension. Make sure you limit this approach, but if you need an extension, you can do it based on our example.


Liskov Substitution Principle

According to the Liskov Substitution Principle, it allows every client to use any subtypes even without knowing. You won’t affect the resulting behavior, and that also means the clients are isolated, and they don’t know any of the class hierarchy changes. For programmers, what this means is that any object specialization, class, or subclass will need to be suitable for the SuperClass or the designated parent. 

One of the primary advantages of the Liskov Substitution Principle is that it works very well for object-oriented software designs. It’s all about creating hierarchies. The subclasses connect to classes, and they stay close to the parent class. Pursuing class compatibility leads to better results.

Common highlights of this principle: 

- Any driven/concrete class should be able to substitute parent class (or interface) without the consumer knowing it. A common example of this would be changing the database engine from a file-system to a Relational/NoSQL database without consumers knowing (and remain unaffected) of such change.

- Every part of the code should get the expected result no matter what instance of a class you send to it.


Interface Segregation Principle

According to the Interface Segregation Principle, clients should never be forced into creating methods and even interfaces that they don’t intend on using. If you have a class and you want to add a new interface method, then the other ones will need to declare it or you see an error.  The client must add only methods that need to be used, as this will prevent any possible errors that might arise. This principle recommends replacing fat interfaces with many small and more specific interfaces.

Dependency Inversion Principle

Last, you have the Dependency Inversion Principle. This principle is crucial to keep in mind because it shows you need to depend mostly on abstractions and not any sign of concretions. If you have high-level modules and low-level ones, they will not depend on each other, instead, they focus on abstractions. And the abstractions themselves shouldn’t depend on any details either.

When you have a high-level component, don’t make it depend on the low-level modules. Instead, your focus has to be on making the right change to the code to see both modules being abstraction-dependent, as that’s what matters here.

The purpose of this principle to be able can change the implementation of a low-level code (for example - changing database engine) without changing high-level code (consumer code). While making the change, the focus should be on abstraction instead of what the database engine does and how it does.


Is It Mandatory to Learn the SOLID Principles?

Every developer knows that following the right principles can make a huge difference, and it will also eliminate most of the hassle related to the development practice. The challenge here is that many of these things will take a little to understand and get into. But they work well, they deliver a tremendous value, and in the end, you will be impressed with the process.

The toughest thing for a lot of people when it comes to adhering to these principles is the fact that they need practice. You can’t get it right off the bat, so practice makes perfect. By following our guidelines and examples you will have no problem implementing a very good set of SOLID principles. These are a great starting point and you will appreciate the way everything comes together. With time, implementing the SOLID principles will help you create cleaner, better, and more cohesive code. This also helps you ensure that the software you create runs without errors, which will bring in front of a very good user experience!

Share post

  •  
  •  
  •  
  •  

Tilak S.

Technology freak, Open Source lover. Someone trying to understand many things. Wants to make a difference. Life liver and Peripatetic.

Other posts you might like