Principios SOLID para ser mejor programador

Está claro que, en el mundo del desarrollo de Software, uno de los libros más relevantes de los últimos años ha sido sin duda Clean Code, el libro del tío Bob (Robert C. Martin).

Uno de los mensajes con los que me he quedado de ese libro es el de que los desarrolladores, además de ingenieros capaces de resolver problemas debemos vernos a nosotros mismos como escritores, de forma que no es suficiente con que nuestro código funcione bien, sino que debemos poner nuestro mejor esfuerzo en que se entienda bien. Que cuando otro desarrollador lo lea tenga la sensación de que le estás contando una historia acerca de cómo funciona el sistema. De hecho, el tío Bob afirma que la legibilidad y limpieza del código es más importante que el hecho de que funcione correctamente. El argumento es que, si el código es limpio será mucho menos costoso mantenerlo y arreglar cualquier fallo mientras que si no lo es, por muy bien que funcione, más temprano que tarde se hará muy difícil de mantener y evolucionar.

Además de hablar de lo que él considera que es un código limpio a nivel de funciones, módulos, comentarios, tests… da una serie de ‘code smells’ o heurísticos que nos dan pistas de cuando un código no es todo lo limpio que debería.

A principios de la década de los 2000, éste autor formuló un acrónimo de 5 principios básicos del diseño y la programación orientada a objetos. La idea es que al aplicar estos principios, los sistemas software resultantes son más fáciles de mantener y ampliar con el tiempo. El acrónimo de estos principios es SOLID, y son los siguientes:

S’ingle responsability principle (principio de responsabilidad única)

Lo que nos dice este principio es que una clase debería tener una única responsabilidad. Normalmente ésto se expresa cómo que una clase debería tener una única razón para cambiar. Si una clase tiene más de una responsabilidad no se estaría cumpliendo este principio. Esa clase sería más sensible al cambio y su mantenimiento se complicaría.

‘O’pen/closed principle (principio abierto/cerrado)

Las entidades de software (funciones, clases, módulos…) deberían estar abiertas para su extensión y cerradas para su modificación. Dicho de otra manera, ha de ser fácil poder extender su comportamiento sin modificar el código fuente original.

‘L’iskov substitution principle (principio de sustitución de Liskov)

Este principio dice que una clase que hereda de otra debe poder utilizarse en lugar de su clase padre sin que se modifique el comportamiento del sistema. Las clases hijas siempre deberían poder sustituir a la clase padre de forma totalmente transparente.

‘I’nterface segregation principle (principio de segregación del interfaz)

Es preferible tener muchas interfaces cliente específicas que una gran interfaz de propósito general. Los clientes de un programa sólo deberían conocer de éste los métodos que realmente usan, y no los que no necesitan utilizar. Una interfaz grande y compleja debería escindirse en otras más pequeñas y específicas de forma que cada cliente use sólo aquella que necesite.

‘D’ependency inversion principle (principio de inversión de dependencia)

El software debería depender de abstracciones, no de implementaciones concretas.

Echa un vistazo al código con el que estás trabajando hoy. ¿En qué medida dirías que cumple estos principios?

Comparte

Deja una respuesta

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