Press "Enter" to skip to content

Los principios básicos SOLID en POO

Los principios básicos SOLID

SOLID es un acrónimo inventado por Robert C. Martin en donde establece 5 principios básicos para el diseño en la programación orientada a objetos.

S – Single responsability ( Responsabilidad Única)

Este principio básicamente indica que cada clase debe tener una finalidad concreta y única, de modo que no podemos añadir métodos que no correspondan con la clase creada.

Lo que pasa es que muchas veces hemos sido tentados a añadir metodos dentro de una clase que no corresponde por el simple hecho que lo necesitamos en el instante, por lo cual es hora de que dejemos esa práctica y hacer que las clases cumplan algo concreto.

O – Open/closed (Abierto/Cerrado)

Este principio indica que las entidades que creamos deben estar abiertas para su extension y cerradas para su modificación, básicamente es crear clases que se puedan extender, sin necesidad de entrar al código fuente y modificarlo, en otras palabras encapsulación.

L – Liskov substitution (Sustitución de Liskov)

Este principio indica básicamente que lo objetos que provienen de una clase padre pueden sustituir al padre sin que esto altere el funcionamiento del sistema.

Es decir si tenemos la clase B que extiende a la clase A, en nuestro sistema podemos utilizar la clase B y esta debería ser tratada como la clase base, recalcando sin que esto altere el funcionamiento del sistema.

I – Interface segregation (Segregación del interface)

Cuando se definen interfaces deben tener una finalidad concreta, es mejor tener varios interfaces con pocos métodos que sólo un interface con muchos. Es decir los metodos abstractos de la interfaz a crear deben estar sujetos a la finalidad concreta de la interfáz, de forma similar al principio S (Solid responsability) pero esto específicamente a interfaces.

D – Dependency inversion (Inversión de dependencias)

El objetivo de este principio es conseguir desacoplar las clases por medio de abstracciones para conseguir que una clase interactue con otras clases sin que las conozca directamente.

Muchas veces algunas de nuestras clases dependen de otras, pero debemos de encontrar la manera de que este no sea un acoplamiento fuerte, de forma tal que no dependemos explícitamente del Objeto, sino de una manera abstracta. Un poco difícil de explicar pero para esto ya existen patrones como la inyección de dependencias que aplica este principio.


Si seguimos estos principios veremos que nuestras clases serán de mejor calidad y se podrán mantener de mejor manera en el futuro, reutilizaremos más código y serán más seguras.

Adolfo Cuadros
Adolfo Cuadros

View all posts