Published on

Los 5 principios SOLID para el desarrollo de software

Authors

Principios SOLID. SOLID es un acrónimo mnemónico introducido por Robert C. Martin ​a comienzos de la década del 2000 ​que representa cinco principios básicos de la programación orientada a objetos y el diseño.

Cuando estos principios se aplican en conjunto es más probable que un desarrollador cree un sistema que sea fácil de mantener y ampliar con el tiempo. Pero en el fondo, los principios SOLID es solo una guía para desarrollar software.


Principios SOLID

S  (Single-Responsability Principle) Principio de responsabilidad única
O  (Open-Closed Principle) Principio abierto y cerrado
L  (Liskov Substitution Principle) Principio de sustitución de Liskov
I  (Interface Segregation Principle) Principio de segregación de interface
D  (Dependency Inversión Principle) Principio de inversión de dependencias


Descripción de cada principio

Single-Responsability Principle

Principio de responsabilidad única, mide el grado de cohesión de un módulo esta relacionado entre sí. Un clase debe tener sola una razón para cambiar. Una clase debería tener una única responsabilidad. Un error sería aplicar dos cambios de comportamientos distintos en la misma clase.

En programación orientada a objetos, se suele definir como principio de diseño que cada clase debe tener una única responsabilidad, y que esta debe estar contenida únicamente en la clase. Así:

  • Una clase debería tener solo una razón para cambiar
  • Cada responsabilidad es el eje del cambio
  • Para contener la propagación del cambio, debemos separar las responsabilidades.
  • Si una clase asume más de una responsabilidad, será más sensible al cambio.
  • Si una clase asume más de una responsabilidad, las responsabilidades se acoplan.

Open-Closed Principle

Principio abierto y cerrado, nuestras clases, módulos deben ser abiertas para la extensión pero cerradas para la modificación del código ya existente. Modificar lo existente, significa que podemos introducir errores, que hay que modificar nuestros test, hay que revisar el código de nuestros clientes.

El principio abierto-cerrado se puede lograr de muchas otras maneras, pero una de ellas podría ser mediante el uso de la herencia o mediante patrones de diseño de composición como el patrón de estrategia .

Liskov Substitution Principle

Principio de sustitución de Liskov, en que momentos las sustitución de una clase por otra puede alterar la corrección de un problema. Otra forma de expresarlo sería, cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.

Su definición formal sería: si S es un subtipo de T, entonces los objetos de tipo T en un programa de computadora pueden ser sustituidos por objetos de tipo S (es decir, los objetos de tipo S pueden sustituir objetos de tipo T), sin alterar ninguna de las propiedades deseables de ese programa

Interface Segregation Principle

Principio de segregación de interface, los clientes de un programa dado sólo deberían conocer de éste aquellos métodos que realmente usan, y no aquellos que no necesitan usar. Por lo tanto, un cliente no debería ser forzado a usar métodos que no necesiten.

Dependency Inversión Principle

Principio de inversión de dependencias, es una forma específica de desacoplar módulos de software. Este principio dice que los módulos de alto nivel no deberían depender de los de bajo nivel, ni las abstracciones de detalles. Lo que hace que los módulos de alto nivel sean independientes de los detalles de implementación del módulo de bajo nivel:

  • Los módulos de alto nivel no deberían depender de los módulos de bajo nivel. Ambos deberían depender de abstracciones (p.ej., interfaces).
  • Las abstracciones no deberían depender de los detalles. Los detalles (implementaciones concretas) deben depender de abstracciones.

La mejor definición para este principio lo encontré en palabras de un instructor de la plataforma Platzi, Hector Benitez:

"Este principio habla de cómo podemos desacoplar nuestro código, nos dice que no debemos crear clases con dependencias muy estrictas, por ejemplo, si tenemos una clase A y dentro del constructor creamos la instancia de una clase B. Podríamos decir que la clase A está muy acoplada con la clase B por que una depende directamente de la otra y por lo tanto será más complicado mantenerlas en caso de que necesitemos modificar su funcionamiento, por otro lado si inyectamos un objeto de la clase B en lugar de crearlo, estamos dividiendo un poco más el control al dejar la creación de la clase B fuera de nuestro constructor, pero mejor aún, si en lugar de que nuestro método reciba la clase B recibe una abstracción superior, como una clase abstracta o una interfaz, pues estamos desacoplando aún más nuestro código y serás capaz de intercambiar objetos externos a esta clase sin que por ello se afecte el funcionamiento de la misma, en este momento tendrás bajo acoplamiento y una mejor estructura en tu proyecto"

Fuentes:
  • Martin, Robert C. (2003). Agile Software Development: Principles, Patterns, and Practices (en inglés). Pearson Education. ISBN 9780135974445.
  • wikipedia
  • Hector Benitez (Platzi) - Principios de programación SOLID

803