Category Archives: SOLID

SOLID

The SOLID principle helps in reducing tight coupling, which means a group of classes are highly dependent on one another which we should avoid in our code. The opposite, which is loosely coupled classes that minimize changes in our code, helps in making code more reusable, maintainable, flexible, and stable.

This principle is an acronym of the five principles which is given here below:

  • Single Responsibility Principle: This principle states that “a class should have only one reason to change” whoch means every class should have a single responsibility or single job or single purpose. Let’s take an example of the developing software, the task is divided into different members doing different things as front end designes to design, the tester does testing and back end developer takes care of back end development part then we can say that everyone has a single job or responsibility.
  • Open/Closed Principle: This principle states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” which means we should be able to extend a class behavior, without modifying it. Let’s for example, suppose developer A needs to release an update for a library or framework and developer B wants some modification or add some feature on that then developer B is allowed to extend the exiting class created by developer A vt developer B is not supposed to modify the class directly.
  • Liskov’s Substitution Principle: The principle was introduced by Barbara Liskov in 1987 and according to this principle “Derived or child classes must be substitutable for their base or parent classes”. This principle ensures that any class that is the child of a parent class should be usable in place of its parent class should be sable in place of its parent without any unexpected behavior.
  • Intterface Segregation Principle: This principle is the first principle that applies to Interfaces instead of classes in SOLID and it is similar to the single responsibility principle. It states that “do not force any client to implement an interface which is irrelevant to them“. Here your main goal is to focus on avoiding fat interface and give preference to many small client-specific interfaces. You should prefer many client interfaces rather than one general interface and each interface should have a specific responsibility.
  • Dependency Inversion Principle: Before we discuss this topic keep in mind that Dependency Inversion and Dependency Injection both are different concepts. Most people get confused about it and consider both are the same. Now two key points are here to keep in mind about this principle.
  • High-level modules/classes should not depend on low-level modules/classes. Both should depend upon abstractions.
  • Abstractions should not depend upon details. Details should depend upon abstractions.

I chose this topic because, after learning a little more about design patterns, front end, back end, I was curious to learn about SOLID principles and, also I wanted to understand more about it and how it reinforces the need for design patterns in Software.

SOLID Principle in Programming: Understand With Real Life Examples – GeeksforGeeks

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Putting the ‘O’ in SOLID

We
covered the Open/Close principle in a recent lab, and it prompted a desire to
cover some of the SOLID principles. I have determined however, that the length
of this blog is short enough that I should dedicate it to a single principle at
a time, beginning with the aforementioned Open/Close principle.

              This particular object-oriented
principle was outlined by Bertrand Meyer and states:

“…entities should be open for extension, but closed for modification.”

              This of course, is a complex way
of expressing a simple guideline for software development; which is that new
functionality should be able to added without having to radically change existing
code. The operative word, extension, is illustrative. If your code was a home,
and you wanted to add more square-footage (read: functionality), you shouldn’t
need to knock all the walls, or the whole thing, down to add a bathroom.

              In the blog chosen, the author summarizes
a talk he gave about the very subject. In it, he provides an example of a program
he is developing for a company that calculates the total area of a set of rectangles.
As the customer requests more and more shapes be added to the calculator, the original
code changes drastically and gets longer and longer. This modification is opposed
to this principle. In opposition, creating a Shape class that contains many children
of different specific shapes – each with their own area function – with the
ability to add more, eliminates constant modification of the main class, and
allows for constant extensionability in the form of new shapes.

              To say simply that code should be
modular is unhelpful, as it is broad and the general definition of so many more
good coding practices. Our class and homework provide another perfect example.
Why should we have to constantly Override and rewrite portions of a superclass’
methods in each of its child classes to achieve proper functionality. Instead, in
making a Quack/Fly Behavior interface we have established a broad mold that
many new behaviors can be built off of; access to all of which is then granted
by the relationship to the single respective behavior interface.

              Therefore, the ability of code to be
extended with new functionalities, using a single reference – in this case the behaviors,
or shapes – instead of needing to rewrite or overwrite code is what is meant by
extension; while keeping the existing code from needing constant revisions, is being
closed for modification. Like the house example earlier, you should constantly be
building out, not renovating what exists already.

Sources:

A
simple example of the Open/Closed Principle

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.