Mientras más aplicaciones pasan por mis manos, más lamento la mala preparación que recibí en la escuela con respecto al diseño de una aplicación. La separación del mundo académico y el mundo real en la carrera de "Ciencias de la computación" de La Habana es tan grande que en el transcurso de la carrera no se mencionan cosas como "Arquitectura de 3 capas", "Capa de acceso a datos", "Capa de de negocio", ni mucho menos me enseñaron cómo se diseña un modelo de negocios en una aplicación del mundo real.
En la escuela (al menos en la UH), increíblemente, la mayoría de las aplicaciones que se deben entregar como tarea son aplicaciones sin persistencia, con lo cual nuestros super galardonados y reconocidos profesores nos privaron de la desagradable (pero tan necesaria) experiencia de enfrentarnos a los problemas de OR-Mapping, ni a decisiones sobre si utilizar una base de datos orientada a objetos o una relacional.
Uno de los principales problemas con el que me encuentro al iniciar cada aplicación (y ya van siendo muchas), es el de diseñar un modelo del negocio que no me complique demasiado la vida cuando haya que añadir la persistencia, y que a su vez, me permita la gran flexibilidad de la orientación a objetos, y que no me haga obtener de la base de datos un objeto completo para actualizar una relación del mismo. Me explico mejor:
Supongamos que tengo una clase "Autor" y una clase "Libro", y que en este modelo de negocios que invento yo, un Libro sólo puede tener un Autor mientras que un Autor puede escribir muchos Libros, es decir, que existe la relación 1-n entre Autor y Libros.
Si ésta fuera una aplicación para la escuela, en la cual habrá 10 autores y 50 libros, el "juego de programar" consistiría en crear una clase "Autor" con una lista de "Libros"... ahh, pero que distinto sería todo si pensáramos que nadie invierte dinero en una aplicación que gestion 10 autores y 50 libros, y que en el mundo real esta aplicación debería ser capaz de gestionar miles de autores y cientos de miles de libros y brindando al usuario una velocidad de interacción "aceptable".
Si pensáramos en esto veríamos que con el modelo propuesto parece imprescindible obtener de la base de datos (o servicio de persistencia, en general) una instancia completa de un Autor, ¡incluyendo la lista de todos sus libros!, sólo para añadir un nuevo libro, una operación que, aunque en ciertas aplicaciones podría ser aceptable, es indudablemente ineficiente.
Ahora imagínense hacer este tipo de análisis y tomar una decisión para cada clase en un dominio complejo, sin tener ninguna guía ni ningún patrón al respecto. Imaginen a todos los programadores, al menos los que hacen el curso de "Ciencias de la computación" en la Universidad de La Habana y los que hacen el curso de "Ingeniería Técnica en Informática" en la Universidad Rovira i Virgili de Tarragona. Sólo la Universidad Oberta de Catalunya (UOC) ofrece cierto entrenamiento de este tipo.
No divago más, que el tema es complicado de explicar y la idea central ya está dicha:
No es lo mismo "jugar a programar" que hacerlo de verdad, y en la escuela nos enseñan el juego.
No comments:
Post a Comment