Understanding the SOLID principles

In this post, I will discuss the book section "Understanding the SOLID principles" written by Edward Guiness.

SOLID is an acronym that stands for five widely accepted principles of object-oriented programming and design. It is important to know and understand clearly these principles:

Single Responsibility Principle
This principle tells us, that a class should have exactly one responsibility and exactly one reason that cause it to be changed. As I can see, this principle is very important in the design phase. We must remember that we are searching for high cohesion and low coupling.

Open/Closed Principle
This principle states that a class should be open for extension but closed for modification. When we make a modification in the base class, we can break the behavior of child classes, this principle should be applied in the areas that change most likely. 

Liskov Substitution Principle
This principle intends to keep that happy working relationship between classes and functions :). LSP forbids modification of that behavior through the mechanism of inheritance. Flexibility is important!


Interface Segregation Principle
This principle says to avoid writing monstrous interfaces that burden classes with responsibilities they don' need or want, instead we should create a collection of smaller, discrete interfaces, partitioning interface members according to what they concern. This means, be simple, just add the necessary classes that provide the methods to accomplish the objective of each class, and no more.


Dependency Inversion Principle
This principle says to "depend upon abstractions, not upon creations." We should write code that refers to interfaces or classes, and not in another way. 


In conclusion, after reading and understanding what the solid principles consist of, I think they are so useful to write better code, to avoid dependencies and to develop software faster and better, and the system resulting from this process will be easy to maintain and extend, without making a disaster.

Comentarios

Entradas populares de este blog

Software Craftsmanship

Microservices

Who Needs an Architect?