KISS my SOLID

O cómo crear código limpio y mantenible

Transcript

1. KISS my SOLID O cómo crear código limpio y mantenible
2. Besa mis brillantes principios sólidos
3. Pero primero, ¿qué es SOLID? Es un acrónimo que representa cinco principios básicos de la programación orientada a objetos (sí, copy paste de la wikipedia). Estos cinco principios fueron creados para ayudar a los programadores a crear un código más sencillo, mantenible y ampliable que sin ellos.
4. S de Single responsability (o responsabilidad única) “Una clase debe tener sólo una razón para cambiar” Robert C. Martin. Es decir, que una clase (también aplicable a funciones) debe de tener solo un cometido (o responsabilidad), de forma que a la hora de trabajar con el código solo debemos cambiarla si el cambio está estrechamente relacionado consigo misma y no como “daño colateral” a partir de otro cambio que poco tiene que ver con ella. Para ello lo que haremos será separar las responsabilidades y aumentar la granularidad de nuestras clases.
5. S -> Ejemplo
6. O de Open/Closed (Abierto/Cerrado douh! ) En corto: abierto a la extensión pero cerrado a la modificación, es decir, debemos crear clases extensibles de cara a ampliar su funcionalidad pero cerradas a su modificación de forma podamos usar esta de base de cara a trabajar con sus extensiones. Un uso concreto sería la herencia de clases donde creamos una funcionalidad básica en una clase padre y a continuación la extendemos en forma de hijos de la misma. Además, esta misma clase padre puede ser abstracta, generando en sí misma un contrato para con sus hijos, formando una interfaz robusta cerrada a modificaciones pero abierta a extensión
7. O -> Ejemplo
8. L de Liskov substitution (spanglish obvio) “Si sabes conducir, da igual qué coche sea, puesto que seguirá siendo un coche y por tanto podrás conducirlo correctamente” Yo. Bastante relacionado con lo anterior nos explica que: al generar objetos derivados de una clase padre estos deben de ser fácilmente intercambiables entre ellos e incluso por el padre sin alterar el correcto funcionamiento del conjunto. Simplificando el concepto sería, tratar al padre como un contrato de sus hijos de forma que pudiéramos utilizar las clases hijas como si de la clase padre se tratara.
9. L -> Ejemplo
10. I de Interface segregation (...) “Muchas interfaces específicas son mejores que una genérica” Tu amigo y vecino Robert C. En sí es bastante sencillo y está relacionado con S (single responsability), y quiere decir que es preferible crear varias interfaces con responsabilidades muy acotadas que una más grande que describa más funcionalidad que la que en muchos casos se va a requerir. Dado que las interfaces son contratos de funcionalidad, al implementarlas nos comprometemos a completar toda esta funcionalidad, pero en interfaces extensas esto puede ser innecesario por un lado y superfluo por otro.
11. I -> Ejemplo
12. D de (dedo) Dependency Inversion (Inversión de dependencias) “Abstracción en vez de concreción” si, Tito Robert El objetivo de este principio es abstraer nuestro código en la medida de lo posible de los detalles de implementación, frameworks, librerías y en resumen dependencias que deberían ser lo más externas posibles. Además de ello deberemos minimizar las dependencias de nuestros objetos de forma que sean fácilmente sustituibles (mocks)
13. D -> Ejemplo
14. Bola extra! KISS Quizás lo más importante después de todo este muermo, es que, sobretodo: KEEP IT SIMPLE, STUPID! La simplicidad debe ser el objetivo a la hora de diseñar software y por ello evitar introducir complejidad innecesaria.
15. ¿Preguntas?