Back-end

S.O.L.I.D Principles

Introducing S.O.L.I.D Principles

Share:

If you have mastered and used OOP then you likewise need to learn SOLID because they are two different things.

OOP can be defined as a programming paradigm that relies on the concepts of classes and objects. This paradigm is used to structure software programs into straightforward and reusable blueprint of code or code classes. These classes are subsequently used to create individual objects in programming.

Whereas SOLID is a principle. SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. The principles are a subset of many principles promoted by American software engineer and instructor Robert C. Martin (a.k.a Uncle Bob) first introduced in his 2000 paper Design Principles and Design Patterns.

The main goal of solid principles is to reduce dependencies so engineers can change one area of software without affecting others. By following solid principles, the code created is easy to understand, maintain, and extend. Ultimately, using these design principles makes it easier for software engineers to avoid issues and to build adaptive, effective, and agile software.

S — Single Responsibility

A class should have one and only one reason to change, meaning that a class should have only one job.

O — Open/Closed

Objects or entities should be open for extension but closed for modification.

L — Liskov Substitution

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

I — Interface Segregation

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

D — Dependency Inversion

Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.

Summary

 
Case Study Mobile