Los principios SOLID son un acrónimo recopilado por Robert C. Martín en su libro Clean Architecture.
Nacen de la Programación Orientada a Objetos y sirven para Diseñar Programas.
- Tolerantes al cambio
- Fácil de entender
- Reutilizables
Para mí son recomendaciones y guías nos muestran cómo crear, Clases, Métodos, Interfaces, etc. correctamente y conforme a la POO.
En mi Curso de Diseño Orientado a Objetos y Principios SOLID te enseño todo desde cero y paso a paso con ejemplos reales, te dejé un regalo en este link para que lo adquieras a un precio especial.
Objetivo de los Principios SOLID
Su principal Objetivo basado en la POO es:
Crear software de la forma más modular posible.
Al tener software y sus componentes con esta calidad nos permitirá ensamblarlo e intercambiarlo como si fueran Bloques de Lego.
Principios SOLID uno a uno de manera general
(S) Single Responsibility Principle
Significa: Responsabilidad Única pero, se entenderá mucho más si lo definimos como: «Que un elemento de un programa tenga solo una sola razón para cambiar»
Cada componente debe ser sumamente independiente pero al mismo tiempo tener las capacidades de conectarse con otros para trabajar y resolver tareas más complejas.
(O) Open / Closed Principle
«Abierto por extensión pero cerrado para modificación»
Aquí nos enfocamos en pensar cómo hacer crecer el software o en otras palabras, hacerlo Escalable.
El software debería poder crecer sin dolor, si añadir algo nuevo provoca una multitud de cambios puede ser que tengamos que abrir un montón de clases y modificarlas.
Precisamente para evitar este dolor el principio dice que los elementos deben ser Cerrados para Modificación.
Pero entonces, ¿cómo añado algo nuevo?
Si añadirlo significa ensamblarlo o conectarlo como un bloque de Lego, ¡Bingo! tu diseño es escalable.
(L) Liskov Sustitution Principle
Barbara Lizkov fue la creadora de este principio.
La definición compleja dice:
Por cada objeto O1 del tipo S existe un objeto O2 del tipo T, cuando O1 es sustituído por O2 entonces S es un subtipo de T.
Pero en otras palabras podemos decir que:
En una jerarquía de clases padre e hijos. Los hijos deben cumplir por completo con la naturaleza de su padre sin hacerse pasar por otras clases
(I) Interface Segregation Principle
Significa: Segregación de Interfaces.
Segregar Interfaces viene de la acción de dividir, y para dividir correctamente una Interfaz hay que seguir pensando en las responsabilidades que debe tener.
Cuando implementas una interfaz en una clase, esta debe estar diseñada para que a todos sus métodos les escribas un comportamiento.
Si por alguna razón al implementar una interfaz estás dejando métodos vacíos esta es una señal de que tal vez tiene muchas responsabilidades, por lo que necesitarás segregarla o dividirla.
(D) Dependency Inversion Principle
El principio dice:
Los módulos de alto nivel no deberían depender de los de bajo nivel.
Ambos deberían depender de abstracciones
Lo primero que hay que diferenciar es que la Inversión de Dependencias es diferente a la Inyección de Dependencias.
El Objetivo de la Inyección de Dependencias es suministrar objetos a un elemento en lugar de ser él mismo quien los cree.
Por otro lado el diferenciador del Principio de Inversión de Dependencias es su última parte: Ambos deberían depender de abstracciones.
A cualquier nivel que lleves este principio, desde un método, una clase, un módulo etc. La Inversión de dependencias se verá al depender de Abstracciones en lugar de cosas concretas.
Los elementos más abstractos que tenemos en Kotlin son: Clases Abstractas y las Interfaces.
El objetivo de este Post es darte un panorama general sobre los Principios SOLID, visita todos y cada uno por separado en nuestro sitio web para que tengas más comprensión con ejemplos de código.
En mi Curso de Diseño Orientado a Objetos y Principios SOLID te enseño todo desde cero y paso a paso con ejemplos reales, te dejé un regalo en este link para que lo adquieras a un precio especial.
😊 Gracias por comparitr haces un excelente trabajo divulgando conocimiento.
