KISS es la abreviatura de “Keep it simple, stupid” o traducido, “Manténlo simple, estúpido”. La idea es que el código debe hacerse siempre lo más sencillo posible. Esto ayuda a que haya menos errores y a que sea más fácilmente mantenible en un futuro, ya que será más fácil entenderlo por terceras personas y corregir posibles errores que queden.OO es la orientación a objetos. Un código diseñado con orientación a objetos debe usar cosas como clases, herencias, polimorfismos, encapsulación, etc. Tras muchos años de diseño orientado a objetos, se ha llegado a que hay determinadas formas de combinar clases e interfaces para obtener unos resultados óptimos, los llamados patrones de diseño. Como consecuencia, un buen diseño orientado a objetos normalmente implica el uso de determinados patrones de diseño. También, en un buen diseño orientado a objetos, se usan varias clases cada una de ellas con una responsabilidad concreta muy definida, es decir, suelen ser clases pequeñas y que sólo hacen cosas concretas. El fin último de la orientación a objetos es conseguir que el código sea reutilizable. Podemos llevarnos a otros proyectos sólo aquellas clases que realmente necesitamos y además, están hechas de tal manera, que no es necesario modificarlas, sino que nos sirven tal cual.

Pues bien, KISS y OO, hasta cierto punto son opuestos y veamos un pequeño ejemplo tonto. Imagina que vamos a hacer un programa que pida al usuario por pantalla los coeficientes de una ecuación de segundo grado y nos muestre el resultado por pantalla.

Si llevamos KISS a sus últimas consecuencias y tratamos de hacer el código lo más simple posible, sin preocuparnos en absoluto de posible reusabilidad de lo que hacemos, lo más sencillo es hacer una única clase con un método main(). En ese método pedimos por pantalla los coeficientes (podemos hacer un método estático encargado de pedir un número por pantalla), echamos las cuentas (podemos meterlas en otro método estático) y sacamos los resultados (si acaso en otro método estático). Resultado final: una clase sencilla, que hace lo que tiene que hacer, con quizás tres métodos además del main(), pero que no es en absoluto reusable. Hace lo que hace y nada más. Sólo pide coeficientes por pantalla, echa unas cuentas y saca los resultados por pantalla.

Si pensamos más bien en hacer algo reusable y aplicamos orientación a objetos, posiblemente hagamos una clase EcuacionSegundoGrado a la que le pasemos los coeficientes y nos devuelva los resultados. Haremos otra clase (o dos clases) para pedir y sacar cosas por pantalla. Estas clases, idealmente, deberían implementar interfaces de pideDato() y muestraDato(), de forma que si más adelante en vez de pantalla es una base de datos, nos baste con implementar esas interfaces. Finalmente, posiblemente hagamos otra clase más con un main() encargada de instanciar las anteriores y hacerlas funcionar conjuntamente. El resultado final es que tenemos una serie de clases con responsabilidades separadas y reusables. Podemos coger cualquiera de esas clases y llevarla tal cual a otro proyecto y usarla a nuestro gusto.

Pero…. hemos perdido la sencillez. Ojo, no quiero decir que estas clases no estén bien hechas o que sean dfiíciles de entender si están bien hechas, pero donde antes teníamos una única clase y siguiendo el main() lo veíamos todo, ahora tenemos tres o cuatro clases, dos interfaces y seguir el código nos obliga a navegar de una a otra … y navegar a través de una interface no es sencillo, puesto que no sabemos qué implementación hay detrás (en este ejemplo sí sabemos cual hay detrás, porque sólo hay una). Obviamente, todo esto es peor si nuestro programa no es tan tonto como una ecuación de segundo grado.

¿Cual es entonces la situación ideal?. Las metodologías ágiles, en general, nos dan la solución bien clara. Haz el código lo más simple posible sólo para lo que tienes que hacer ahora (la historia de usuario concreta que estás haciendo ahora, el bug que estás corrigiendo, etc).

Si tenemos una historia de usuario que dice que pedimos los coeficientes por pantalla, resolvemos la ecuación y mostramos por pantalla los resultados, debemos, sin dudarlo, hacer la primera implementación, la del KISS puro y duro, tal cual nos aconsejan las metodologías ágiles. Cualquier metodología ágil nos aconseja también a hacer test automáticos de prueba. de forma que si más adelante tenemos que rehacer, tengamos seguridad de no estropear.

Supongamos ahora una segunda historia de usuario que nos dice que los coeficientes se deben leer de base de datos. Bien, este y no otro es el momento de hacer la interface con el método pideCoeficiente(), hacer dos implementaciones, la de pantalla y la de bd, y cambiar nuestro código para que no vaya directamente contra pantalla, sino contra esta interface cuya implementación alguien le pasará de fuera. Al tener test de la primera parte, tendremos seguridad de no haber estropeado lo que ya funcionaba después de tocar y ya habremos empezado nuestro diseño OO, por necesidad, y no por gusto. Ojo, todavía no hemos extraido la clase EcuacionSegundoGrado ni hemos hecho metodo en la interface de muestraResultado(), porque nadie nos ha pedido mostrarlo en otro sitio que no sea pantalla.

Resumiendo, es muy importante para tener un código lo más claro posible, no lanzarse sin ton ni son a hacer clases, interfaces, aplicar patrones y usar a tope la OO. Hay que ser realista y usar esas características de OO sólo cuando es estrictamente necesario o cuando estamos seguros al 99% de que vamos a necesitarlas. En el ejemplo anterior, si tenemos la lista de historias de usuario en algún sitio y vemos que la segunda está justo detrás de la primera, quizás, y en contra de las metodologías ágiles estrictas, podamos ir haciendo la interface ya en la primera implementación.

Visto en: Diario de Programación de Chuidiang