Skip to main content

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:


Popular posts from this blog

Sprint 3 Retrospective Here is the Link to the repositories that contains everything we worked on Sprint-3. Backend, Frontend, Event system, and Keycloak. Connect RabbitMQ receive file to DB : Connected the MongoDB database on the received file. Implement Event System components: Implemented RabbitMq components for Event System. Meet with other Event System Teams. : Met with other teams to finalize everything about messages. New TheasPantryReport: The new Theas Pantry Report Create two channels for both teams: Created two channels for both teams on the send and receive files.   For this Sprint, I worked mainly with Austin on the backend components such as implanting the rabbbitMQ, making API, and trying to get out system working. What worked well / did not work well For this sprint, what worked best was that we got our reporting system functioning. We have a system where the Rabbitmq receives the message f