Las anotaciones y el buen (mal) uso de ellas

“Syntactic sugar causes cancer of the semicolon” Epigrams on Programming”, Alan Perlis http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html

Todos los que conocen Java, Groovy, C# y un sinnúmero de lenguajes que las soportan, conocen de las bondades de las anotaciones para muchos propósitos, algunos de ellos muy útiles y otros sin utilidad alguna. Estos últimos, en lugar de favorecer la simplicidad y entendimiento del código, conducen en ocasiones a pasar por alto muchos conceptos importantes que los diseñadores y programadores deben conocer para lograr un producto de software de calidad. Una de las consecuencias de ese “pasar por alto”, es que al tener la necesidad de moverse a otro lenguaje que no hace uso de anotaciones, y presentarse la necesidad de aplicar esos conceptos, comienzan a presentarse los problemas.

Lo que escribo en esta nota es producto de una conversación (usando las bondades de Twitter) que recién tuve con un colega y amigo de varios años, acerca del uso de la anotación @Singleton en el lenguaje Groovy y la ausencia de la misma en el lenguaje Java, para indicar (anotar) que una clase debe actuar como una pobre fábrica capaz de generar un solo objeto.

Esa restricción es parte de la semántica de la clase, o dicho en palabras simples, concierne exclusivamente al código que se necesita dentro de la clase para no permitir que los que la usan puedan instanciar objetos y utilicen entonces otro mecanismo para obtener la referencia al objeto creado por métodos de la propia clase. La anotación entonces afecta directamente el tipo de elemento anotado y se aparta del objetivo de este constructo que debe ser (lo dejo en inglés): “Annotations provide (meta) data about a program that is not part of the program itself. They have no direct effect on the operation of the code they annotate.”

Si consideramos que esta afirmación previa es cierta, entonces tendríamos que preguntarnos si @Singleton tiene o no un efecto directo sobre la operación del código que anota, para, partiendo de ese precepto, decidir si es una anotación correcta, o si sólo se trata de “ázucar sintáctica” que endulza la píldora de Groovy. Si estoy escribiendo esto, podrá imaginar el lector mi respuesta a tal pregunta y esa es que, es incorrecto restringir con una anotación, que una clase funja como Singleton, pues de manera directa afecta y mucho la operación del código que anota.

Hay otras cosas que no justifican el uso de @Singleton. Siempre que analizo las posibles ventajas de anotar algún código trato de responder a interrogantes como las siguientes:

1. ¿Tiene la anotación un efecto directo en la operación del código que anota?
2. ¿Dónde está el código o datos de boilerplate, que necesita “la parte” del programa que anoto (con RetentionPolicy!=SOURCE), para que ella realice correctamente su trabajo?
3. Si la política de retención es RetentionPolicy.SOURCE, ¿Qué tan compleja puede ser la sintaxis de la anotación para parametrizar el código generado, comparado con el código escrito por el programador?
4. ¿Es la sintaxis de la anotación (con RetentionPolicy.SOURCE) más comprensible que el código que se requiere escribir si ella no se usa?
5. ¿Puede un IDE con sus wizards generar con facilidad el código necesario sin hacer uso de la anotación (con RetentionPolicy.SOURCE)?
   
6. ¿Genera la anotación el código acorde al contexto de ejecución?

Si el código que genera Groovy para @Singleton (de acuerdo con http://groovy.codehaus.org/Singleton+transformation) es:


Entonces, no lo utilizaría para un contexto de ejecución de un solo hilo de ejecución.
Adquirir el monitor puede costar caro.