Las clases con muchos datos y poco código delatan al “analista” improvisado.

? Supongo que estará usted tan familiarizado como un servidor con esa plaga tan extendida de nombrar directores de informática a gente cuyo único mérito es la voluntad de mando (que no es lo mismo que saber mandar). Esta epidemia es aún más dañina gracias a los vendedores de pociones mágicas y a ciertos evangelistas de UML. Estos últimos quieren que creamos que se puede mecanizar la programación. Claro: éste es el sueño de cualquier jefe de departamento, y la gente suele creerse aquello que confirma sus más íntimos deseos. UML es particularmente nocivo porque puede inducir a los profanos a creer que diseñar una aplicación compleja es algo que se puede lograr a golpe de dibujines. ¡Es que incluso Microsoft publicita Visual Studio mostrando a una panda de nerds que cubren la superficie de un parque con extraños diagramitas! En alguna "píldora" le contaré todo lo que tengo contra UML, pero no en ésta.Los problemas aparecen cuando el analista improvisado intenta aplicar lo que él (o ella) cree que es eso de la P.O.O. (por cierto, ¿sabe lo que significa poo en inglés?). Bueno, seamos justos: incluso para un buen programador, es complicado explicar las ventajas de la Programación Orientada a Objetos. Entre otras razones, porque un buen programador asimila estas ventajas en su fuero interno, como si se tratase de su segunda naturaleza. Por lo tanto, las clases que salen de la pizarra del analista improvisado contienen, principalmente, campos y propiedades. Sin embargo, lo importante, que es saber cómo se encapsula el código, cómo se distribuyen las responsabilidades en el sistema, queda casi siempre a cargo del programador situado administrativamente en un escalón más bajo. El programador terminará resolviendo el problema... y esto sólo servirá para reforzar el prestigio de su jefe.Es momento de ponernos serios: hay que desconfiar de las clases que sólo encapsulan datos. Si tiene en sus manos un sistema que ya funciona, intente identificar qué clases han usurpado las responsabilidades de la clase sospechosa. Si está todavía en la fase de análisis y comprensión del sistema, intente ayudarse identificando qué debe hacer la clase en cuestión: sólo después de identificar esas responsabilidades, intente mover a la clase la información necesaria para cumplir con sus tareas.