¿Hacer una aplicación comercial en Squeak? (Parte 1)
Antes que nada, un poco de contexto.
Mantenerse actualizado en un ambiente tan dinámico como el mundo Java es bastante complejo (no digo que sea el único ambiente complejo, sino que lo es… otros -como el mismo Squeak-, han demostrado serlo también). Para poder incorporar en proyectos comerciales novedades tecnológicas es preciso tenerlas bien probadas, así no se le hace pagar al cliente los costos de una investigación o una implementación fallida. Para hacer eso, a veces ocupo tiempo de mi trabajo (cuando no estoy asignado a proyectos), pero la mayor parte del tiempo investigo en mi casa, cuando estoy aburrido. Así, investigué frameworks que luego fueron incorporados en mi trabajo como estándares, como JSF y GWT.
El principal banco de pruebas con el que trabajo es un juego online que estoy desarrollando de a poco, juego de estrategia espacial, con algunas novedades con respecto a los cientos que ya pululan por la red.
Bien. En ese contexto es que estoy realizando mi “prueba” con Squeak.
Los parámetros de medición, siempre subjetivos, serán comparaciones entre los distintos elementos del juego, antes "GWT Planets" y ahora "Squeak Planets" que estoy haciendo.
Dicidí como primer paso migrar lo que ya tenía hecho en Java a Smalltalk. Primero pensé que sería un trabajo engorroso, sin embargo se demostró que no era cierto, hay muchas cosas que no necesito migrar, y que en Java “ensuciaban” mi código y en Smalltalk/Squeak no. A saber:
a) No necesito configuración (en Java lo tenía con Spring). Todos los objetos se configuran a si mismos, en métodos de objeto o de clase.
b) No necesito interfaces!
c) En java, la tendencia es a poner todos los métodos creacionales en “Abstract Factories”, que crean, buscan, etc. objetos del sistema.
En Smalltalk, la mayoría de veces no es necesario. Con aplicar el patrón “Method Factory” alcanza y sobra.
d) La persistencia: en Java, dado que necesito inicializar el sistema cada vez que vpoy a probar algo, necesito rápidamente ir al mapeo de datos (con Hibernate), para poder tener un set de datos de prueba.
En Smalltalk, no.
Como tengo un ambiente de objetos vivos, con tener el set de datos que necesito, alcanza. Por supuesto, en algún momento esto tendrá que resolverse… pero no ahora, cuando estoy desarrollando. No tengo que preocuparme por algo que en definitiva es secundario.
Con respecto a esto, en realidad ocurrió algo gracioso al principio: como estaba acostumbrado a la forma java de desarrollar, estaba en principio definiendo objetos con Ids, confundido en la forma de poder acceder a ellos. En realidad, no hay necesidad de esto, los ids son una consecuencia de la persistencia (y de la persistencia relacional en particular)… ya lo resolveré cuando lo necesite, por ahora, todo corre correctamente en la imagen, en donde tengo un universo de objetos fácilmente alcanzable.
e) No necesito capas. No hay que dividir el diseño en capas de: aplicación, lógica, acceso a datos, etc. con un dominio de objetos bien definidos alcanza.
Por supuesto, alguien dirá que es preciso establecer una división analítica, con lo cual estoy de acuerdo… al menos en algunos casos, no en todos.
Sin embargo, lo que es una división analítica, no tiene por qué ser física (por ejemplo, el patrón DAO, es una abstracción absolutamente innecesaria en el contexto de mapeos ORM… pero eso lo discutiré más adelante).
¿Parece poco?
Con estos cambios, mi universo de objetos se redujeron de más de 150 clases en la versión Java a poco más de 30 en Smalltalk.
Además del código compacto logrado, se gana en mantenibilidad dado que todo lo relacionado con el ciclo de vida de un objeto esta en un único lugar, no distribuido entre n capas, cada una de las cuales hace un pequeño segmento de lo necesario.
Y si hablamos de productividad, es cierto que gran parte del dominio lo tenía definido en la primer versión, ¡Pero tardé dos semanas en traducir un código que me costó más de seis meses en desarrollar!
En cuanto tuve estos elementos definidos, solo me faltaba empezar a realizar la interfaz de usuario… pero eso queda para el próximo post.
posted by Esteban @ 12:37 PM
0 Comments
