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