sábado, mayo 10, 2008

Ejercicios calisténicos para objetos

Acabo de leer un post de Andrew Binstock al que he llegado saltando de aquí para allá mientras procrastinaba un poco. Andrew leyó en "The ThoughtWorks Anthology", uno de los últimos libros de la serie "Pragmatic Programmers" un capítulo dedicado a la "calistenia para objetos" (Object Calisthenics) escrito por Jeff Bay.

La palabra es un poco rara así que he investigado un poco sobre ella.

Calistenia f. La calistenia es el ejercicio físico destinado a desarrollar las fuerzas musculares.

Es una palabra que ha entrado en el castellano de la palabra inglesa callisthenics, y estos del griego καλλος (kallos = hermoso), y σθενος (sthenos = fuerza).

En realidad creo yo que el autor no se refiere a la calistenia de los objetos, sino la del programador. De hecho, las normas no son para los objetos, sino para los que los escriben. Los ejercicios  son nueve, y los resumo a continuación.

1. Usa sólo un nivel de indentación por método. Si al escribir un método necesitas un nivel más, significa que tienes que crear un nuevo método al que llamarás desde aquél.

2. No utilices la palabra clave else. Si la condición no se cumple, debes salir del método. Esto evitará el famoso código sinusoidal al no permitirse cadenas de elses.

3. Esconde las cadenas y los tipos primitivos en clases. Esto se llama "obsesión por las primitivas" y no tiene nada que ver con las féminas de Atapuerca. Significa que si representas un código postal como una cadena de 5 dígitos, debes crear una clase CodigoPostal que esconda la cadena.

4. Utiliza sólo una instrucción punto por línea. Eso significa que te tienes que OlvidarDe.Llamar().AUnMetodo().TrasOtro() en la misma línea y UtilizarSolo.UnaLlamada()

5. No abrevies los nombres. Este punto no lo he entendido, pero parece ser que favorece este tipo de llamadas => Alumno.Matricular(), frente a este otro => Alumno.MatricularAlumno(). Como no lo he entendido muy bien lo cito y pido vuestra opinión:

Don't abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy --if you have to type the full name of a method or variable, you're likely to spend more time thinking about its name. And you'll avoid having objects called Order with methods entitled shipOrder(). Instead your code will have more calls such as Order.ship().

6. Haz que las clases y los paquetes (á la Java) sean pequeños. Por lo visto la heurística es no más de 50 líneas por clase y no más de 10 clases por paquete, lo que favorece mantener la cohesión y el acoplamiento controlados. De gratis, las clases te cabrán en la ventana del IDE.

7. No utilices ninguna clase con más de dos variables de instancia. Opina Andrew que esta es quizá la más dura de seguir, Según Bay, si tienes más de dos variables hay motivos para pensar en agruparlas en otra clase (de dos en dos, claro está). Como bien apunta un anónimo, lo tenemos crudo para programar la clase PuntoEnElEspacio, que necesita claramente tres variables.

8. Utiliza colecciones de primera clase. Lo que significa que tu clase Alumnos debe tener una única variable de instancia: una tabla hash, un array, o lo que sea. Pero sólo una variable.

9. No utilices setters, getters o propiedades (¿alguien tiene alguna sugerencia para traducir getter y setter?). Propiedades caca. Por lo visto esta regla favorece la encapsulación, obliga a la implementación de inyección de dependencia, según el principio de "ordena, no preguntes" (tell, don't ask).

Como yo tengo la misma duda que Patrick Dubroy sobre si esto va de coña o no, me he propuesto analizar cada uno de ellos. Como el artículo puede ser muy largo, voy a dejar cada reflexión en un post distinto, y así también descanso un poquito :-).

Seguiremos informando.

No hay comentarios: