Ruminations of a Programmer: Scala Self-Type Annotations for Constrained Orthogonality

Ruminations of a Programmer: Scala Self-Type Annotations for Constrained Orthogonality

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.

Programación Orientada a Aspectos con AspectJ


Cada día más, la Programación Orientada a Aspectos (AOP) adquiere más importancia para el desarrollo de aplicaciones empresariales.
Aquellos que utilizan Spring como base para sus aplicaciones, conocen el uso que ese marco de trabajo hace de AOP para resolver problemas complejos, siendo la administración de transacciones la más vista. Sin embargo, otros muchos aspectos (y valga la redundancia) no son resueltos de una manera sencilla conociendo solamente el modelo que Spring sigue para ese estilo de diseño y programación. Es necesario conocer y dominar el lenguaje AspectJ para aprovechar al máximo la integración de éste con Spring.

A continuación describo el contenido del curso de AspectJ que BestS2S ofrece, bien como curso cerrado a empresas o abierto al público. Bienvenido los interesados.

Curso de Programación orientada a aspectos con AspectJ

• Instructor: Dr. Bárbaro Jorge Ferro Castro
• BestS2S Software Solutions, S.A. de C.V
• México, D.F.
• Duración del curso
• 24 horas en sesiones de cuatro, seis u ocho horas
• Informes
• informes@bests2s.com

Objetivo del curso

Este curso tiene el objetivo de lograr que los participantes adquieran los conocimientos necesarios para aplicar el lenguaje AspectJ en el diseño y construcción de aplicaciones empresariales. El curso, siendo en esencia un curso práctico con múltiples ejemplos, aborda también conceptos importantes de la programación orientada a aspectos, que de alguna manera complementan conceptos importantes de diseño y programación y en particular de la programación orientada a objetos.

Beneficios para el desarrollador de software

Si bien el área del desarrollo de software y de la programación orientada a aspectos (AOSD y AOP) es desconocida en muchas empresas dedicadas a la producción de software, su presencia en muchas aplicaciones y marcos de trabajo es cada día más significativa, y ha dejado de ser un campo meramente académico, para convertirse en una técnica práctica que contribuye al diseño correcto de aplicaciones empresariales, donde la modularización de los concerns se convierte en una de las metas principales para el diseño arquitectónico de esas aplicaciones.

En ese terreno de la modularización, AOSD y AOP son técnicas de diseño y programación imprescindibles para llevar a vías de hecho las mejores prácticas, y AspectJ en particular se adecua a la tecnología de Java con una curva de aprendizaje poco inclinada que le permite al conocedor de Java convertirse en conocedor de AspectJ en poco tiempo.

Con este curso, los participantes adquirirán los conocimientos que necesitan para explotar las bondades de AOP y mejorar sustancialmente el diseño arquitectónico de las aplicaciones que construyen. También, incrementarán su dominio de las técnicas orientadas a objetos que “salen a la luz” al sumergirse en la búsqueda de soluciones con AOP para evitar diseños y códigos dispersos y mezclados que atentan contra muchos de los principios del diseño de aplicaciones.

Los beneficios de cada tópico particular de AOP se describen más adelante para cada Tema del contenido del curso.

Contenido del curso

1. Introducción a la Programación Orientada a Aspectos (AOP)

• Fundamentos de la programación orientada a aspectos
• La anatomía de un lenguaje de aspectos
• Los conceptos fundamentales de AOP
• Analogía de AOP con otras tecnologías
• Introducción rápida a AspectJ
• Los aspectos en un programa con AspectJ: primer ejemplo

Competencias adquiridas con el Tema 1

• Entender el significado de “crosscutting concerns”
• Encapsular en módulos los “crosscutting concerns”
• Responder con precisión las siguientes preguntas:
• ¿Dónde están los aspectos en un programa que no usa AOP?
• ¿Cómo puedo crear módulos con los aspectos de un programa?
• ¿Cuántas implementaciones de AOP existen?
• ¿Para qué aprender AspectJ si ya conozco Spring AOP?
• ¿Si Groovy brinda AOP (¿será cierto?), por qué no lo brinda Java?
• ¿Para qué aprender AOP si algunos consideran que su uso es limitado?

2. Introducción a AspectJ

• Dominando los conceptos principales con un ejemplo (learning by example)
• Disección del código ejemplo
• Construyendo la aplicación con líneas de comando y con Eclipse.
• Las “cosas” para expresar “crosscuttings” en AspectJ: puntos de unión, cortes y aspectos
• Las “cosas” para diseñar y construir “crosscuttings dinámicos”: los avisos
• Las “cosas” para diseñar y construir “crosscuttings estáticos”: las introducciones y declaraciones en tiempo de “tejido”
• El uso de anotaciones para una sintaxis alternativa
• Entendiendo los mecanismos de tejido
• La integración inevitable de AspectJ en Spring

Competencias adquiridas con el Tema 2

• Programar aspectos con AspectJ
• Distinguir lo estático de lo dinámic
• Conocer lo que Spring ofrece de AspectJ
• Responder con precisión las siguientes preguntas:
• ¿Qué valor me brinda conocer las “tripas” del mecanismo de tejido de AspectJ?
• ¿Para qué usar línea de comandos si dispongo de Eclipse u otro IDE?
• ¿Para qué tantos puntos de unión si quizá baste con las llamadas a métodos?
• ¿Qué ventajas tiene modificar el modelo de objetos de un diseño con las introducciones de AspectJ?

3. Puntos de unión, cortes, avisos, introducciones y aspectos con detalle

• Dominando los conceptos con un ejemplo (learning by example)
• El modelo de puntos de unión en AspectJ
• Categorización de los puntos de unión
• El lenguaje de expresión y los patrones de firmas para los cortes
• Los avisos para la construcción de crosscuttings dinámicos
• Clasificación de los avisos de AspectJ
• Avisos y métodos: similitudes y diferencias
• El contexto de los puntos de unión. Exposición del contexto a los avisos
• Acceso al contexto mediante técnicas de reflexión
• Las declaraciones inter-tipos de AspectJ
• Los patrones de diseño de GOF programados con introducciones de AspectJ

Competencias adquiridas con el Tema 3

• Dominar el modelo de puntos de unión
• Expresar los cortes usando las dos sintaxis disponibles
• Diseñar patrones de diseño con AspectJ
• Utilización del contexto de los puntos de unión en los avisos de los aspectos
• Determinar las necesidades de cortes dinámicos y estáticos
• Modificar la estructura de las clases y objetos mediante declaraciones inter-tipos
• Responder con precisión las siguientes preguntas:
• ¿Cuáles son las ventajas de un modelo rico de puntos de unión?
• ¿Qué ventajas tiene el uso de AOP en la programación de patrones de diseño?
• ¿En qué contextos es importante la precedencia de aspectos?
• ¿Cómo presentar un modelo de diseño que se programa con aspectos?
• ¿Qué técnicas pueden usarse para modelar aspectos con UML?
• ¿Cómo tener acceso al contexto de ejecución de un programa con aspectos?

4. La integración de AspectJ con el marco de trabajo Spring

• Las limitaciones de AOP en Spring
• Los detalles de Spring AOP
• Programación orientada a aspectos basada en proxies dinámicos
• El soporte para @AspectJ en Spring
• La inyección de dependencias para la configuración de aspectos
• La selección del sistema AOP adecuado para aplicaciones con Spring

Competencias adquiridas con el Tema 4

• Programar aspectos con las facilidades de Spring AOP
• Justificar las limitaciones de Spring AOP
• Describir las diferencias entre tejido de código y proxies dinámicos para la implementación de los aspectos
• Describir la función de DI en la configuración de aspectos
• Responder con precisión las siguientes preguntas:
• ¿Qué ventajas y desventajas tiene la técnica de proxies dinámicos?
• ¿Qué tanto debe usarse de AspectJ en una aplicación con Spring?
• ¿Para qué tantos puntos de unión si quizá baste con las llamadas a métodos?

5. Aplicaciones de AspectJ con Spring

• Técnicas de monitoreo
• Cumplimiento del código con las políticas y decisiones del diseño
• Patrones de diseño
• Control de la concurrencia
• Administración de las transacciones de la aplicación
• Implementación de la seguridad de la aplicación
• Mejoras significativas con aspectos a la lógica de negocio de la aplicación

Competencias adquiridas con el Tema 5

La más importante que se espera del curso: APLICAR AOP PARA RESOLVER PROBLEMAS REALES EN APLICACIONES REALES


La empresa Bests2s

Fundada en 2009 por un grupo de doctores reconocidos en las áreas de Computación, Informática e Inteligencia Artificial, “Bests2s Soluciones y Servicios de Software, Desarrollo Académico y Capacitación” es un equipo formado por profesionales del software altamente capacitados en soluciones basadas en tecnología de Java, Inteligencia de Negocios y en Sistemas Inteligentes así como también en el desarrollo académico y la capacitación en estas tecnologías.

Con un promedio de 20 años de experiencia en Consultoría, Docencia, Desarrollo Académico y Capacitación, la fortaleza de Bests2s reside en su gente. Este experimentado equipo de trabajo provee liderazgo técnico, liderazgo académico, experiencia en las mejores prácticas, mejores principios y mejores procesos, en el manejo de proyectos y en el desarrollo de sistemas de software.

La esencia de Groovy

La esencia de Groovy

Seguramente muchos de los lectores de estas notas tienen una percepción similar a la mía cuando leen los promocionales de los lenguajes de programación, o de los marcos de trabajo, o de los sistemas operativos, o de casi cualquier cosa en la computación. Todos ellos se acompañan de una enorme lista de bondades para resolver los problemas que no resuelven (según ellos) las herramientas que ya existen, conocemos y dominamos.

Edsger W. Dijkstra en EWD 709 My hopes of computing science escribió: “Write a paper promising salvation, make it a 'structured' something or a 'virtual' something, or 'abstract', 'distributed' or 'higher-order' or 'applicative' and you can almost be certain of having started a new cult”. Quizá hoy, Dijkstra habría añadido los términos orientado a objetos, dinámico, metaprogramación y el resto de bondades que acompañan las listas de los lenguajes, que como Groovy, ofrecen la salvación.

Leo, por ejemplo, en uno de los comentarios al libro Programming in Groovy de Venkat Subramaniam lo siguiente: “ … Venkat takes the reader beyond simple keystrokes and syntax into the deep depths of “why?” Groovy brings a subtle sophistication to the Java platform that you didn’t know was missing. Once you see those missing language features in action, you can’t imagine how you ever programmed without them. …” Muchos coincidirán conmigo que lo que he subrayado en el párrafo anterior es un exceso de pasión.

En mayor o menor medida todos reflejamos cierta pasión hacia algunas herramientas y técnicas de la computación aunque no seamos los creadores de ellas. Experimento eso con cierta frecuencia, y en mi rol de profesor universitario lo manifiesto en cambios a los temarios de las materias que imparto, creo que para bien. Con Java me pasó hace ya más de 10 años, cuando decidí cambiar de C++ a ese lenguaje en mis clases de Programación Orientada a Objetos. Hoy estoy experimentando algo similar con los lenguajes dinámicos de moda como es el caso de Groovy que, en su esencia se manifiestan los siguientes “olores”:

Groovy es un lenguaje orientado a objetos que genera código ejecutable (byte code) para la máquina virtual de Java. Toma “prestado” las ideas de otros lenguajes como Smalltalk, Ruby y Python y (una idea excelente) mantiene una sintaxis familiar a la de Java, cosa muy conveniente para los “Javeros”. Como discutiré en otras notas para este blog, Groovy no solamente se adhiere a la sintaxis (con muchos nuevos idioms) sino que también preserva la semántica de Java y extiende el JDK (nuevas clases y nuevos componentes a las clases existentes) para implementar, en un lenguaje muy similar a Java , capacidades propias de los lenguajes dinámicos.

En Groovy, todo es un objeto. Las “instancias” de los tipos primitivos de Java, int, float, double, etc., son objetos y son objetos de verdad hasta en tiempo de ejecución. La porción de código siguiente ilustra este fenómeno - inusual para los que se educaron con la programación orientada a objetos con lenguajes como C++ y Java, pero resulta muy lógico para los amantes de Smalltalk.

1. import java.lang.reflect. Constructor
2. int entero = 5
3. println "Clase de entero ${entero.getClass()}"
4. Constructor c =entero.getClass().getConstructor(int.class)
5. double d = c.newInstance(123)
6. println d
7. println "Clase de d ${d.class}"

La ejecución de este código resulta en:

® Clase de entero class java.lang. Integer

® 123.0

® Clase de d class java.lang.Double

El lector debe notar la existencia en la sintaxis de las palabras claves int y double en las líneas 2 y 5, pero que en esencia declaran objetos de tipo java.lang.Integer y java.lang.Double respectivamente, como puede observarse en el resultado de la ejecución.

Groovy es un lenguaje de guión (del inglés scripting language). Puede notarse en la porción de código anterior que, comparado con Java, no tenemos necesidad de escribir todo “un programa” para ejecutar pedazos de código. Lo que estamos haciendo es usar las capacidades de Groovy como lenguaje de guión y ejecutar ese código con su intérprete. Es el intérprete el encargado de completar “lo que falta” para la ejecución. Si es de su interés ver lo “que falta” puede compilar ese bloque de código y decompilar el byte code generado. Seguramente le parecerá muy complicado pero sin entrar en detalles, se puede realizar una disección del código fuente obtenido para entender un poco las entrañas de Groovy. Por lo pronto es suficiente con decir que, a partir de ese código, el intérprete genera una clase con un método estático main a “la Java” e incluye las sentencias ejecutables en ese método. El trabajo del intérprete nos ayuda a entender “paso a paso” las cosas del lenguaje sin necesidad de tener que escribirun programa completo. Piense por un momento en las ventajas de ésto para los primeros cursos de programación. Vendrán otras cosas interesantes de Groovy para estos menesteres.

Groovy es un lenguaje dinámico, con capacidades que no están presentes en los lenguajes estáticos. Y aquí podría venir una discusión eterna acerca del dinamismo y estatismo de los lenguajes de programación. No me dejo tentar por esa discusión y por lo pronto, para entender la esencia de Groovy, basta con decir que el término lenguaje de programación dinámico se usa en la literatura de manera vaga para denotar aquellos lenguajes de programación que permiten hacer en tiempo de ejecución cosas que otros lenguajes pueden realizar exclusivamente en tiempo de diseño o compilación. Entre esas cosas están la de poder extender los programas añadiendo nuevo código, extendiendo objetos y definiciones, modificando el sistema de tipos, etc.

Sucede que esos lenguajes como Groovy, que se promueven como lenguajes dinámicos, también manejan los tipos dinámicos. En el caso de Groovy existe la opción de los tipos estáticos y los tipos dinámicos lo que representa una gran ventaja para quien, viniendo del mundo de Java, quiere comenzar con Groovy “poco a poco” y continúa especificando sus tipos para todos los “ciudadanos de primera clase” en sus programas. En la porción de código siguiente hemos eliminado los tipos, y el resultado de su ejecución es el mismo.

1. import java.lang.reflect. Constructor
2. entero = 5
3. println "Clase de entero ${entero.getClass()}"
4. c =entero.getClass().getConstructor(int.class)
5. double d =(double) c.newInstance(123)
6. println d
7. println "Clase de d ${d.class}"

La ejecución de este código resulta en:

® Clase de entero class java.lang. Integer

® 123.0

® Clase de d class java.lang.Double

Groovy es un lenguaje ágil de poca “ceremonia” que maneja una sintaxis más simple (una vez que nos acostumbramos a ella) y que sigue la filosofía de “Convention over configuration” o “Coding by Convention” que no significa otra cosa que considerar en la codificación, la especificación explícita de las cosas no convencionales y dejar implícito lo convencional, lo que casi siempre usamos. Por ejemplo, para que escribir que una clase es pública si casi siempre (¿será?) lo es.

No sé si al decir que es un lenguaje de “poca” ceremonia” transmito la idea. Es una frase que utiliza el autor de “Programming in Groovy” para indicar la sencillez de la sintaxis o ausencia de lo barroco en el texto de un programa en Groovy.

Groovy es un lenguaje que le otorga ciudadanía de primera clase a otras cosas, entre ellas a las funciones aumentando así la población de literales en el lenguaje. Las funciones en un lenguaje de programación son funciones, objetos, o ciudadanos de primera clase si el lenguaje permite tratarlas como cualquier otro objeto de primera clase y eso implica que:

Puedan expresarse con literales anónimos

Puedan almacenarse en variables

Puedan ser utilizadas como partes de una colección

Tengan una identidad con independencia de su nombre (que los objetos tengan una identidad inherente es una condición del paradigma de objetos.

Puedan ser comparadas por identidad con otras funciones

Puedan ser pasadas como parámetros en la invocación de otra función

Puedan ser retornadas como el resultado de una función

Tengan una representación textual

Puedan participar en un ambiente de cómputo distribuido (pasadas a otras máquinas virtuales como objetos remotos)

Puedan ser persistentes

Creo que se necesita un ejemplo para ilustrar todas estas características de los objetos de primera clase. Si mi intención es que lo que escribo sea leído, entonces una buena manera de lograrlo es suspender el episodio en un momento interesante, y creo que éste instante se presta. Aun faltan cosas importantes de la esencia de Groovy, quizá una de las más relevantes. Lo dejamos para la próxima.

Comienzo con Groovy

Hace unos días comencé a estudiar Groovy.
Me interesaron algunos "pedazos" de código en esa lengua, pero sobre todo me llamó la atención la forma tan enfática en que sus fans hablan de la implementación del protocolo de metaobjeto en Groovy.
Me acordé entonces del libro "The Art of the metaobject protocol" de Gregor Kyczales y otros (el mismo Gregor de AspectJ) y de la importancia para el paradigma orientado a objetos, que tiene la metaprogramación al estilo de MOP, quizá una de las cosas más relevantes de ese paradigma y de la importancia que (en los momentos actuales con todo el ruido de los sistemas que evolucionan en ejecución) tiene para el diseño y construcción de software.
Algo más vimos (varios colegas y yo) de interesante en este lenguaje, además de su posible incidencia en el terreno de la industria de software. Ese algo más tiene que ver con usarlo como un primer lenguaje en los cursos de programación de los primeros semestres de la carrera de ingeniería en computación (con diferentes nombres en diferentes institucuiones). Quizá y seamos de los primeros en hacerlo, y por supuesto corremos el riego de ser pioneros.
Esto me animó aun más a seguir leyendo y escribiendo código con Groovy.
Quiero escribir en este blog algunas cosas del lenguaje , que ya escribo en mi cuaderno con el objetivo de preacticar mi caligrafía.
Así empiezo y espero no terminar pronto, pues hay mucho que decir.

Olvidé el URL

Cuando me propuse empezar este Blog, tuve el temor de olvidar hasta el URL del mismo. Así sucedió. Basta con observar la fecha del último post.
Con toda intención he agregado el gadget de seguidores de este blog. Como puede observarse, aun no tengo seguidores. ¿Quién sigue lo que no existe?
Espero que esta vez pueda darle continuidad a este proyecto. He seleccionado un momento difícil por la cantidad de trabajo, pero a veces los momentos difíciles son los de mayores recompensas.
¿De qué voy a (re)comenzar a escribir?. Aun no lo sé pero seguramente tendrá que ver con lo que hago.
Para tener seguidores pronto tendré que ofrecer algo para que algunos de mis amigos y estudiantes lean lo que escribo. El ofrecimiento será temporal. Después quedarán encantados con la lectura.

Demasiado tiempo dedicado a leer y poco a escribir

Hoy comienzo este blog. Espero no olvidar su url.