S.O.L.I.D Principles

 This week on my CS Journey, I want to talk about the SOLID design principles. I am sure that you have heard the term many times, however, let us look at the principles in detail. The reason I picked this topic is as a Computer science major student we write many programs and having a strong principle will enable us to write effective object-oriented code. 

To start of SOLID is an acronym where each letter represents a software design principle. 

S - for Single Responsibility Principle

O - for Open/Closed Principle

L - for Liskov Substitution Principle

I - for Interface Segregation Principle

D - for Dependency Inversion Principle

 

Each principle overlaps here and there. The Single Responsibility Principle states that in a well-designed application, each class should have only one single responsibility. essentially meaning a class should only have one job. I think this is a very good concept to use because when you are working with complex programs and the class has more than one responsibility it will become a nightmare. The open-closed principle states that classes should be open for extension but closed for modification. For example, I learned that if you want to add a new feature to your program you should do it by extending it rather than modifying it which minimizes the risk of failures. Next, the Liskov Substitution Principle which explains that an object of a superclass can be replaced with objects of its subclasses without causing problems to the application. This means that a child class should never change the characteristics of its parent class.

 

The  Interface Segregation Principle is the fourth SOLID design principle that states no clients should not be forced to depend on methods they don’t use.  In other words, interfaces shouldn’t include too many functionalities since the interfaces are difficult to maintain and change over time, so it is best to avoid. Lastly, the Dependency Inversion Principle states that the High-level modules or classes should not depend on low-level modules/classes and both should depend upon abstractions because a change in one class can break another class which is very risky.

 

Overall, the blog I read talked about each principle in detail using various examples such as UML diagrams, Java programs, and other diagrams that helped me to understand each concept. I learned a lot from the blog, and I think that these concepts are all key to writing a good solid code. In the future, I will be using the principles to write effective object-oriented code. 

 

 

Here is the blog I Used:

https://raygun.com/blog/solid-design-principles/