En este post hablaremos sobre los primeros 5 principios de diseño de la programación orientada a objetos S.O.L.I.D que significa:
- S : Single-responsibility principle
- O : Open-closed principle
- L : Liskov substitution principle
- I : Interface segregation principle
- D : Dependency inversion principle
Single-responsibility principle
Este principio se puede resumir en que “Una clase debe tener una sola responsabilidad“ al hacer esto tendremos que:
- Crear siempre clases pequeñas
- Si una clase es muy grande dividirla en clases más pequeñas
- No debe existir más de una razón para modificar una clase
Como vemos este principio es violado constantemente por código legado ya que muchas veces tienen clases con un sólo método y cientos de líneas de código, lo cual las hace difíciles de mantener, escalar y probar.
Open-closed principle
Este principio se puede resumir en que “Una clase debe estar abierta a extensiones, pero cerrada a modificaciones” al hacer esto tendremos que:
- Estar abiertos a agregar funcionalidad a nuestras clases
- Evitar modificaciones en ellas
- Utilizar atributos privados y crear getters y setters pero solo cuando se necesiten
- Utilizar clases abstractas con la funcionalidad común que no va a cambiar y crear múltiples implementaciones con la funcionalidad específica
Con esto nos aseguramos de tener métodos estables, confiables, con posibilidad de crecer y que al no ser modificados constantemente no van a impactar a otros componentes.
Liskov substitution principle
Este principio dice que “Las funciones que usan referencias a las clases base (padres) deben ser capaces de utilizar los objetos de sus clases hijas sin necesidad de saber que existen” al hacer esto tendremos que:
- Al utilizar herencia, asegurarnos que se cubre la condición IS A (Es un)
- Perro es un Animal, entonces perro puede heredar de animal
- Libro no es un Cuaderno entonces aunque sean similares Libro no hereda de Cuaderno
- En caso de que no se cumpla la condición IS A validar si se puede usar HAS A para evitar usar herencia en lugar de composición
Al respetar el principio de IS A podremos utilizar referencias de clases base apuntando a objetos de sus clases hijas sin necesidad de conocer quienes son.
Interface segregation principle
Este principio dice que “Un cliente nunca debe ser forzado a implementar una interfaz que no utiliza o no debe ser forzado a depender de métodos que el no utiliza” al hacer esto tendremos que:
- Crear interfaces específicas
- Preferir muchas interfaces específicas pequeñas a una interfaz general
- Minimizar la dependencia entre los componentes
Al crear interfaces específicas evitamos interfaces generales que obligan a los clientes a implementar métodos que ellos no necesitan.
Dependency inversion principle
Este principio dice que “Las entidades deben depender de abstracciones y no de implementaciones, un módulo de alto nivel no debe depender de uno de bajo nivel” al hacer esto tenemos que:
- Las abstracciones no deben depender de detalles específicos
- Detalles específicos no deben depender en abstracciones
- Objetos de alto nivel y de bajo nivel deben depender de la misma abstracción
Siguiendo este principio nos aseguraremos que nuestros componentes son fácilmente escalables sin necesidad de impactar a componentes que no deberían.
Conclusión
Al seguir los principios anteriores nos aseguraremos que nuestro código sigue estándares de calidad que permitirán que sea fácil de probar, mantener, escalable y re utilizable.
Para estar al pendiente sobre nuestro contenido nuevo síguenos en nuestras redes sociales https://www.facebook.com/devs4j/ y https://twitter.com/devs4j
Autor: Alejandro Agapito Bautista
Twitter: @raidentrance
Contacto:raidentrance@gmail.com
