principios SOLID

Si te dedicas a la Programación Orientada a Objetos seguramente habrás oído hablar de los principios SOLID ya que es imprescindible conocer estos 5 principios.

Los enunció Robert C. Martin, y todos los desarrolladores los conocen y usan (u omiten con conocimiento) en sus programas para obtener un código organizado, perdurable en el tiempo y robusto pero flexible. ¿Quién no querría algo así?

En este post voy a enunciarlos y a explicarlos brevemente, si quieres entrar más en materia suscríbete a este blog y obtendrás una guía sobre los principios SOLID con ejemplos y mucha más información.

SOLID – Single reponsibility

En castellano también llamado principio de responsabilidad única.

Su definición es: Una clase sólo debe tener una razón para modificarse.

Con este principio lo que se quiere conseguir es que tus programas tengan clases con una finalidad concreta.

Por ejemplo, si tienes una clase que se encarga de recuperar datos de la base de datos debería ser otra la encargada de preparar los datos o mostrarlos por pantalla.

De esta manera consigues que en tus programas haya menos acoplamiento y aumentar la cohesión. Así te será mucho más fácil hacer test y repartir las clases entre las capas de la arquitectura de tu programa de una manera más lógica.

Single responsibility principle

SOLID – Open/Closed

Es el principio de abierto/cerrado.

Su definición es: Las entidades de software (clase, módulo, función, etc.) tienen que estar abiertas a extensiones y cerradas a modificaciones.

Para que tus programas sean flexibles y perduren en el tiempo tus clases, interfaces, etc no deberían modificarse para añadir una nueva funcionalidad, en su lugar debes extenderlas a otras entidades.

Piensa que tienes una clase que representa un mando de control remoto para una televisión, puede cambiar de canal y subir o bajar el volumen. Al tiempo se crea una nueva funcionalidad, cambiar a vista en 3D para los nuevos televisores.

Según este principio la idea es que no modifiques la clase ControlRemote si no que crees una nueva entidad con la funcionalidad de set3D para extender ControlRemote. De esa manera los televisores sin la función 3D no tendrán en sus mandos a distancia un botón 3D que no vale para nada.

Open closed principle

SOLID – Liskov substitution

El principio de substitución de Liskov, su nombre viene de la ingeniera de software americana Barbara Liskov.

Su definición es: Si tenemos una clase B subclase de otra clase A, podremos sustituir A por B sin que nuestro código se vea afectado.

Quiere decir que si tienes una clase padre y otra hija, la clase hija puede usarse en lugar de la clase padre y tu código debe ser igual de válido.

Esto lo habrás hecho un montón de veces en tus programas, cuando usas List en lugar de un ArrayList.

De esa manera podrás programar para interfaces y no para implementaciones, lo cual hará que tu código sea más flexible.

Liskov substitution principle

SOLID – Interface segregation

Conocido en castellano como el principio de segregación de interfaces.

Se define como: Una clase sólo debe conocer aquellos métodos que vaya a usar.

Otra forma de decirlo sería, si una clase no va a usar un método no debe tenerlo.

Aquí suelen entrar en juego las conocidas como fat interfaces, son interfaces que tienen muchos métodos y que al implementarlas en las clases obligan a introducir métodos que no son útiles.

Por lo tanto cuando te encuentres con una interfaz de este tipo, divídela en otras más pequeñas y concretas.

Interface segregation principle

SOLIDDependency inversion

El último es el principio de Inyección de dependencias.

Su definición se divide en dos partes:

A. Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deberían depender de abstracciones.

B. Las abstracciones no deberían depender de los detalles, deberían ser los detalles los que dependiesen de las abstracciones.

Para cumplir este principio tienes que evitar hacer nuevas instancias de una clase compleja dentro de otra.

Para esto utilizarás un inyector de dependencias en tus programas, puede ser alguna librería como Dagger por ejemplo o hacer el tuyo propio.

De esa manera las dependencias quedarán más claras, las capas de arquitectura de tu código quedan separadas y los test se pueden hacer más fácilmente.

Dependency inversion principle

¿Quieres más? Hazte con la guía

Este ha sido un resumen de los principios SOLID. En mi guía de los principios SOLID que regalo al suscribirse a este blog los detallo junto con ejemplos.

Así que ya sabes, hazte con tu copia y domina SOLID para demostrar que tus programas están hechos por un desarrollador de calidad.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *