Tanta | Espíritu digital, soluciones reales | Somos digitales y nos transformamos contigo |

Principios en el diseño del software: KISS, DRY y SOLID

¿Qué es KISS?

Es un acrónimo de la frase inglesa “Keep it simple, Stupid!”

Este patrón lo que nos dice es que cualquier sistema va a funcionar mejor si se mantiene sencillo que si se vuelve complejo. Es decir que la sencillez tiene que ser una meta en el desarrollo y que la complejidad innecesaria debe ser eliminada.

¿Qué es DRY?

Quiere decir “Don’t repeat yourself”.

Cada pieza de funcionalidad debe tener una única, no ambigua y representativa identidad dentro del sistema.

Si se aplica este patrón de forma correcta un cambio en cualquier parte de la funcionalidad de un programa no incluye cambios en partes que no tengan una relación lógica con la funcionalidad cambiada.

Básicamente lo que se intenta evitar con este principio es que no se duplique el código, porque lo que ocurre luego que el mantenimiento será mucho más difícil ya que no sabremos donde tenemos que cambiar cosas porque no están definidas claramente.

¿Qué es SOLID?

Son seis principios del desarrollo orientado a objetos que aplicados juntos facilitan que el desarrollo sea más fácil de mantener y de extender durante el tiempo:

  1. Principio de responsabilidad única (Single responsibility principle)
    Este principio establece que una clase sólo debe tener una responsabilidad sobre el total de la funcionalidad, es decir que para contener el cambio debemos de tener claramente definidas las responsabilidades.
  2. Principio de abierto/cerrado (Open/closed principle)
    Una clase está cerrada a la modificación pero abierta para extenderla.Es decir la clase abstracta o interfaz queda cerrada a la modificación pero está abierta a su extensión o implementación de la interfaz.
  3. Principio de sustitución de Liskov (Liskov substitution principle)
    Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.Es decir que si una clase es un subtipo de otra, los objetos de esta clase subtipo podrían sustituir a los objetos de la clase padre sin que el programa sufriera ningún cambio de comportamiento.
  4. Principio de segregación de la interfaz (Interface segregation principle)
    Dice que los clientes de un programa dado sólo deberían conocer de éste aquellos métodos que realmente usan. Para esto no se deben hacer interfaces de propósito general si esto ocurre habrá que dividirlas en varias interfaces para cada propósito específico.Este principio lo que nos facilita es tener un sistema desacoplado de los sistemas  de los que depende, de forma que sea más fácil modificarlo, redesplegarlo.
  5. Principio de inversión de la dependencia (Dependency inversion principle)
    Dice que se debe de depender de abstracciones no de implementaciones.Se le llama así porque se invierte el flujo tradicional de programación mientras que tradicionalmente era el programador que de forma secuencial decidía cuando se iban instanciando las clases ahora lo que ocurre que determinadas sucesos provocan que a través de un entidad externa en este caso un framework  se lleven a cabo las acciones de control  necesarias para responder estos sucesos.
  6. La inyección de dependencias
    Es un método que sigue este principio, hay bastante confusión con respecto a estos dos términos no son lo mismo. Típicamente la forma de implementarlo es a través de un framework que pone un contenedor de objetos que se van instanciando de forma automática siguiendo una configuración que está especificada en un archivo de configuración de ese framework.

¿Cuáles son nuestras conclusiones?

Respetando estos principios se han desarrollado los patrones de diseño. Los framework de desarrollo a su vez utilizan varios de estos patrones para su construcción.

Aunque utilicemos un framework en nuestro desarrollo esto no garantiza que respetemos estos principios. En nuestro propio código también deberíamos respetarlos. Cuando al desarrollar seguimos estos principios nos podemos preguntar cómo de estrictos tenemos que ser aplicándolos. Algunos autores dicen que hay que seguir la aproximación de orientación al riesgo. Cuanto más riesgo tenga un desarrollo, porque es más complicado o más crítico el sistema, habrá que seguirlos de una forma más estricta.

Tanta
Tanta | Espíritu digital, soluciones reales | Somos digitales y nos transformamos contigo |

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir al contenido