Blog de Gonzalo

PRINCIPIOS SOLID

Los principios solid son una 5 reglas establecidas por Robert C. Martin (Uncle Bob) , que escribió el libro de clean code, donde se habla de como escribir algoritmos fáciles de entender y mantener. SOLID es un mnemotécnico en el que cada letra tiene el siguiente significado:

  • S:Principio de responsabilidad única (Single responsibility principle). Una clase solo debe tener un motivo para cambiar, es decir, que solo debe tener una tarea, una funcionalidad. Por ejemplo si tenemos una clase que obtiene datos de la base de datos y necesitan ser formateados por ejemplo para ser devueltos en json, en un array, o en html. Sería un error tener dentro de la clase, que recupera esas datos, los métodos formateadores de salida. Lo suyo sería tener una clase específica y así puede ser usada por otras clases del proyecto.
  • O:Principio de abierto/cerrado (Open/closed principle). Donde las clases están abiertas a su extensuión pero cerradas a su modifciación. Por ejemplo añadir campos a una entidad o se pueden añadir nuevas funcionalidades al comportamiento pero sin salirse del principio de responsabilidad única.
  • L:Principio de sustitución de Liskov (Liskov substitution principle). Donde una clase que hereda de una clase padre pueda usarse como dicha clase padre sin saber las diferencias entre ellas. Un ejemplo sería tener una interfaz de vehículos con el método acelerar ya sea vehículo de combustible o eléctrico.
  • I:Principio de segregación de la interfaz (Interface segregation principle). Describe que muchas interfaces específicas son mejores que una interfaz genearal, es decir, el programador no debería estar forzado a usar interfaces que no va a usar.
  • D:Principio de inversión de la dependencia (Dependency inversion principle). Donde se debe depender de las abatracciones y no de las implementaciones. Por ejemplo cuando se desarrolla un sitio ecommerce no es lógico tener una clase carrito que tenga los métodos de pago y los métodos de guardar los datos de la compra en base de datos. Lo lógico es tener una clase carrito, un interfaz de pago, con los sus clases con los diferentes métodos de pago y otra clase que va a guardar los datos en base de datos creando el pedido.

Espero que este ejemplo os haya resultado útil y que esté bien explicado.

Compartir en twitter