Eso sí, para todo eso se necesitan programadores con experiencia y buena voluntad. Experiencia para detectar qué cambios conviene hacer (y hacerlos bien) y buena voluntad para hacerlos. Lamentablemente me ha tocado ver aplicaciones que empezaron con KISS porque eran chiquitas y luego se convirtieron en mounstros pero no sufrieron ningún tipo de rediseño, y todos sabemos que eso puede llevar al caos de mantenimiento.

Rules are for Fools, Patterns are for Cool Fools. Journal of Object-Oriented Programming, 10, October 1999.

Por mi parte el principio que casi sigo a rajatabla es el DRY (dont repeat yourself), me chirria tanto ver un codigo repetido mas de dos veces que me supera y tengo que montarme algo para evitar una tercera repeticion (y eliminar las dos anteriores de paso). La abstraccion permite eliminar la repeticion de codigo y reusarlo, aunque la oop no es la unica manera de abstraer…en cualquier lisp (en clojure por ejemplo) por ejemplo el tener closures y poder modificar el codigo en tiempo de evaluacion con macros te permite abstraer muchas veces de forma mas rapida, sencilla y expresiva que con la oop y sus a veces rebuscados patrones.

El problema es cuando antes siquiera de que se repita una vez ya piensas en que tal vez se repita, que tal vez cambie el requirimiento, que tal vez el usuario no sepa lo que quiere, que tal vez…y como cuando haces la maleta la llenas de “por sies” y acabas con el triple de lo que luego usas realmente. Por eso prefiero refactorizar a partir de la segunda repeticion que pensar en las interfaces desde el principio a no ser que este muy muy clara su utilidad.

@blaxter.
ps: Lo del main() con todo junto es posible en este ejemplo porque es muy tonto. En un problema más grande habría más clases y más separación entre cosas. Pero de la misma forma, si para este ejemplo tonto exagerando la OO hay tres o cuatro clases y dos interfaces, para un problema complejo habría tres miles de clases y dos miles de interfaces. Como comenta Gimente, hay que determinar cual es el objetivo de nuestro código y ser consecuente con él. La OO se ha inventado para hacer código fácilmente reutilizable y ampliable. Si nuestro objetivo no es ese, nos sobra la OO y deberíamos usar lo menos posible.
ps2:Doy por sobreentendido que para reutilizar clases estas deben estar compiladas y separadas en una librería fuera del proyecto. Si quiero que mi clase EcuacionSegundoGrado sea retulizable, tendré que hacer mi librería matematica.jar y meter ahí esa clase ya compilada.

Sed buenos.

Un saludo y enhorabuena por el blog, que sigo desde hace bastante tiempo y cada vez está mejor.

ps: Una única clase con un método main y unión de lógica del programa con la GUI eso no es KISS, eso es lo más jodidamente retorcido que se puede imaginar.

ps2: la reutilización de clases es un mito de OO (reutilizar librerías, sí, ¿pero clases individuales? riau, riau).

Hacer una clase con un main() es elegir un “diseño simple”, pero no es “simple de extender”. Por lo tanto, qué quiere decir KISS? “Mantenlo simple en diseño” o “Mantenlo simple de extender” o incluso “Mantenlo simple de usar”. Y con esto último (“simple de usar”) no me refiero a la usabilidad, sino al código: por ejemplo un API simple en su interfaz externa puede ser muy compleja en su implentación.

KISS es algo muy genérico. Puedes mantener simple el diseño o la implementación o… o hacer un equilibrio según las necesidades en cada momento. La OO te permitirá hacer un diseño más simple de extender y de mantener, por lo tanto OO también es KISS

saludos!