Principios KISS, DRY y YAGNI

El código limpio tiene como uno de sus pilares el “menos es más” de toda la vida y se aplica a
diferentes aspectos, y los desarrolladores tenemos algunos acrónimos para algunos de los principios
del código limpio.

Principio KISS – Keep It Simple, Stupid

Evitar la complejidad innecesaria en el código, optar por una documentación simple y concisa, así
como optar por interfaces de usuario limpias y claras.

Este principio también abarca el usar nombres claros para nuestras entidades (variables, métodos,
interfaces, funciones, clases, etc), y esos nombres deberían significar una sola cosa siempre.

Además al separar nuestro software en capas, cada una debe tener responsabilidades bien definidas.

Principio DRY – Don’t Repeat Yourself

No debes tener código duplicado, duplicar hace que el código sea más complejo y extenso, y cuando sea
necesario cambiar alguna parte de este, será necesario cambiar el mismo código en múltiples lugares,
dando lugar a trabajo extra y posibles errores.

Este principio incluye copiar y pegar código ya existente para reutilizarlo, pero también incluye en
pensar y construir código nuevo teniendo en cuenta su posible reutilización.

Y por último también hay que tener cuidado del código que puede estar en múltiples lugares y que
puede lucir diferente, pero que al final de cuentas hace exactamente el mismo funcionamiento.

Principio YAGNI – You Ain’t Gonna Need It

De la mano de todo lo anterior, este principio habla sobre no crear características innecesarias.

Evitar implementar funcionalidades solo porque piensas que posiblemente algún día podrías
necesitarlas, en su lugar podríamos optar por implementarlas cuando realmente sean requeridas.

El principio KISS habla sobre evitar la complejidad innecesaria, YAGNI habla sobre enfocarnos en
evitar lógica y funcionalidad innecesaria y remover características que no se usen o que sean
redundantes.

Siempre será bueno dejar el código mejor de lo que lo encontramos.
Cuando nos encontremos con código que no sea muy claro y no cumpla con los principios anteriormente
descritos siempre podemos dedicar al menos unos minutos para corregirlo.

Principios SOLID

Este acrónimo por Robert C. Martin, engloba otros 5 principios de diseño de software enfocados al
código limpio en la programación orientada a objetos, pero incluso va más allá y apuntan al código
flexible, fácil de entender, extender y mantener.

Aunque antes de explicar los principios solid primero hay que tener en cuenta tres cosas:

• Cada clase que creemos debe servir para un único objetivo claro y bien definido
• Asegurarnos que las clases interactúan entre sí mediante interfaces
• Diseñar interfaces pequeñas y las clases solo deben implementar las interfaces que requieran

S – Single responsibility principle

Cada clase debe tener una única responsabilidad.
Entre más responsabilidades tenga una clase, más seguido será necesario cambiarla, además de que
generará más dependencia en otras clases.
Teniendo clases dependientes genera el problema de que muchas salgan afectadas al hacer un solo
cambio.

O – Open-Closed principle

Este principio habla sobre que las entidades en nuestro código deben estar abiertas a ser extendidas,
pero cerradas a ser modificadas.
Debemos crear código modular que pueda ser extendido sin requerir modificaciones.

Esto se consigue mediante abstracción, herencia e interfaces por ejemplo.

L – Liskov substitution principle

Este principio establece que una subclase debe poder sustituir a la clase base de la que hereda sin
que el código se rompa.

Por ejemplo, teniendo una función que acepta como argumento objetos de una clase A, esta función
debería ser capaz de aceptar también objetos de una clase B que extienden a la clase A y todo
debería seguir funcionando correctamente.

I – interface Segregation principle

El principio de segregación de interfaces establece que múltiples interfaces específicas son mejores
que una única interfaz de propósito general.

En este principio se tiene en cuenta también que una interfaz debe depender más del código cliente
que la llama que del código que la implementa y no debemos obligar al cliente a depender de
interfaces innecesarias.

Por lo tanto, una clase debe implementar diferentes interfaces creadas en función de los diferentes
clientes.

D – Dependency inversion principle

Finalmente tenemos la inversión de dependencias, que es el principio que establece que las clases
deben comunicarse por medio de Interfaces.

El código debe depender de abstracciones y no de implementaciones concretas.