Principios SOLID

arrow_back Blog

Algunos de estos principios son tratados en el curso de arquitectura hexagonal en Laravel.

En ingeniería de software, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) es un acrónimo mnemónico introducido por Robert C. Martin (Uncle Bob) 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.

Los principios SOLID son guías que pueden ser aplicadas en el desarrollo de software para eliminar malos diseños provocando que el programador tenga que refactorizar el código fuente hasta que sea legible y extensible. Puede ser utilizado con el desarrollo guiado por pruebas, y forma parte de la estrategia global del desarrollo ágil de software y desarrollo adaptativo de software.

S: SRP

Principio de responsabilidad única (Single responsibility principle) La noción de que un objeto solo debería tener una única razón para cambiar.

La S de SOLID puede ser el principio más sencillo de entender. Queremos que en este caso una clase sólo haga una cosa, para ello, podemos tener el ejemplo de un controlador que únicamente tiene un método __invoke y se encarga de listar artículos. Con muy pocas línea de código y con únicamente una responsabilidad (listar artículos) cumplimos con este principio.

O: OCP

Principio de abierto/cerrado (Open/closed principle)
La noción de que las "entidades de software deben estar abiertas para su extensión, pero cerradas para su modificación".

La O de SOLID es muy simple, imagina que tienes un proceso de registro en tu plataforma que inicialmente funciona con correo electrónico. Pasado un tiempo te piden añadir Facebook, después Twitter y después Gmail. Al final, si no lo hacemos bien, podemos tener un lío importante a nivel de código.

La forma de solucionar esto es con el siguiente ejemplo, donde inicialmente trabajamos únicamente con correo electrónico, pero si algún día queremos añadir Facebook, sólo deberemos seguir el mismo proceso reutilizando parte de la lógica a través de un nuevo servicio.

L: LSP

Principio de sustitución de Liskov (Liskov substitution principle)
La noción de que los "objetos de un programa deberían ser reemplazables por instancias de sus subtipos sin alterar el correcto funcionamiento del programa".

La L de SOLID es quizá la más compleja de entender, aunque es realmente sencilla. Este principio SOLID dice que cualquiera de las subclases de una clase deben poder reemplazar a su clase padre sin alterar su comportamiento.

Algunas de las reglas a seguir para aplicar este principio son las siguientes:

  • El número de parámetros de entrada en el método de las subclases debe ser igual o mayor que el número de parámetros de entrada del método principal en la clase padre.

  • El tipo de los parámetros de las subclases deben ser del mismo tipo o equivalente que los de la clase padre.

  • Los tipos de los valores devueltos del método de las subclases deben ser iguales o más específicos que los tipos devueltos por el mismo método en la clase padre.

  • Las pre-condiciones para cualquier método en las subclases no pueden ser más que las de la clase padre.

  • Las post-condiciones de las clases hijas deben ser al menos o iguales a las de la padre.

  • Los tipos de excepciones de las subclases deben ser del mismo tipo o más específico que el de la clase padre.

I: ISP

Principio de segregación de la interfaz (Interface segregation principle)
La noción de que "muchas interfaces cliente específicas son mejores que una interfaz de propósito general".

La I de SOLID es muy simple. Este principio SOLID dice es mejor tener muchas interfaces en lugar de una única interfaz que lance excepciones cuando no se pueda implementar. Cabe decir que no debemos crear interfaces en exceso, siempre hay que tratar de ser coherentes para que nuestro trabajo se simplifique al máximo sin caer en el exceso.

Primero vamos a ver un ejemplo donde se viola el principio de segregación de interfaz.

A continuación, veamos cómo quedaría un caso cumpliendo el principio de segregación de interfaz.

D: DIP

Principio de inversión de dependencia (Dependency inversion principle)
La noción de que se debe "depender de abstracciones, no depender de implementaciones".

Siguiendo el ejemplo utilizado en el curso, nosotros tenemos una interfaz para gestionar el repositorio de cursos en lugar de la clase concreta.

Cursosdesarrolloweb Cursosdesarrolloweb

Cursosdesarrolloweb es una plataforma educativa con cursos y tutoriales en texto y vídeo.

Términos y condiciones Política de privacidad Formulario de contacto

Copyright 2024 © Todos los derechos reservados.

Contacto