Day 12 of #100DaysOfCode

The SOLID Principles for good software design

Every software developer must know them

SOLID Principles was introduced by Rober Martin in his book Agile Software Development, Principle, Patterns, and Practices. These 5 design principles are put in a way that its easy to understand and apply them.

Disclaimer

These 5 principles don’t strictly apply anywhere, there will hardly be any system where you would be seeing all five of them applied. Understand what they have to offer and then decide whether to apply them in your system. For some scenarios applying these principles be overkill or might end up over-complicating simple systems.

Let’s look into the principles one by one

1. Single Responsibility Principle

“A class should have just one reason to exist”

In your project, try to make every single class responsible for a single role, and make that role entirely encapsulated within the class. This way you will have a very clean modular code.

If we are not careful enough in following SRP, we end up having multiple or god forbid one God class which actually ends up doing everything. It's fine as long as you never have to come back to make the changes, which is never gonna be the case, you make one change it breaks a lot of other things which you never meant to change so save yourself some pain by following this principle.

Example, you may have Student class which is currently managing its properties along with its attendance. But due to some new rules, there can be a change in attendance logic and hence it's better if Student class responsibility is only to deal with its properties and not the attendance.

Hence, we split Student into Student and AttendenceReport class, now both classes have their own single responsibility.

2. Open Closed Principle

“Classes should be open for extension but closed for modifications”

This rule keeps your existing code reusable while allowing you to add new features without breaking anything in the existing codebase.

When you develop a class, properly test and review it, and finally add it to your framework, and in future, there is a new requirement which requires you to make some changes in the existing class. Instead of modifying the old class (where you risk breaking other things), you should extend the class and override the methods to get the different behavior out of that class.

At the same time, if there are some changes which do require modification, for example — some bug in your class, don’t create a subclass to fix it. Child class shouldn’t be responsible for parent’s issues.

Also, some programming languages offer final keywords which marks a class as close or complete and can’t be used for further extensions.

3. Liskov Substitution Principle

“When extending a class, you should be able to pass objects of the subclass in place of objects of the parent class without breaking anything”

This rule is to help you make sure that if you are creating child classes of a parent class, those child classes must not override any methods so differently that it loses its parent’s identity.

While building a framework this rule is very important to be kept in the mind as it keeps your code classes and subclasses compatible.

Liskov Principle has a checklist you can stick to while following this rule:

1. Parameters type of a method of the subclass should be same or more generalized as that of its parent class subsequent method. Your subclass methods shouldn’t be reducing the capabilities of the parent method, either keep them the same or expand it.
2. The return type must also be either the same or a sub-type of its parent’s class. You cannot generalize the return type. — the quite inverse of the above point for the return type.
3. The child class shouldn’t throw any exceptions that the parent class isn’t supposed to throw. The type of exceptions should be the same or sub-type.
4. A subclass shouldn’t strengthen pre-conditions. If the parent class works with any range of integer values, your child class cannot work only for positive values.
5. A subclass shouldn’t weaken post-conditions. If there is a certain operation being performed like closing up the database connections after each value is returned by each database calls. Your child class cannot keep some database connections opened to be able to reuse them in the future.
6. Invariants of a parent class must be preserved — Your child class must preserve the identity of the invariants of the parent class.
7. Child class shouldn't change any value of private fields of parent class — Some languages do give child class that sort of accesses hence a reminder to not to do that.

That’s all for today folks! Thanks for reading ❤

Let’s take a small break from SOLID Principles for today, we will continue with the other two in the near future.

Remember, if you want to make this learning worth it:

• Go ahead and apply your knowledge and make some good out of it!
• Teach this to someone to learn this again!
• Share this post with a friend whom you think must learn these principles as well.