A medida que voy conociendo nuevos proyectos y aplicaciones desarrolladas por otras personas, me doy aíºn más cuenta de la importancia de proteger y abstraer al desarrollador del modelo de datos en el que asienta una aplicación.
Proteger y abstraer siempre es algo básico, pero sobre todo, si el desarrollo de una aplicación va a llevarse en un modelo de desarrollo de Software-Factory. A continuación expongo alguna de las razones más importantes.
1) La volatidad de los profesionales que trabajan en este tipo de empresas es muy alta.
2) Es habitual que los proyectos estén integrados por un mayor porcentaje de profesionales con experiencia media/baja (becarios, programadores con un año o dos de experiencia…) elevado, liderados por un grupo reducido de profesionales con mayor experiencia (en proyectos de 4 o 5 personas estamos hablando de 1 profesional o 2 realmente qualificado).
3) La formación en las herramientas/tecnologías a utilizar por parte de los miembros del proyecto con menor experiencia es proporcional a los años de experiencia profesional que acumulan.
Con todo este panorama por delante, veo totalmente esencial que el acceso y manipulación del modelo de datos se deba llevar a cabo por los profesionales con más experiencia del grupo, abstrayendo al resto del problema, y centrándolos en el desarrollo de la vista y el controlador. Por supuesto que el desarrollo del controlador se va a basar en llamadas al modelo de datos que hemos protegido, siguiendo unos flujos que el analista funcional debe encargarse de transmitir a los programadores.
¿Cómo llevar a cabo dicha protección y abstracción? A mi modo de ver la mejor forma de realizar esta labor es llegando a crear la sensación al programador de que el modelo de datos no existe, que no hay base de datos. íšnicamente disponemos de un conjunto de clases (agrupadas en un NameSpace, Package…), que representan el modelo de negocio y que cuentan ya con una serie de operaciones asociadas.
Y por supuesto dichas clases son una caja negra, de la cual sólo conocemos su estructura, pero para nada cómo funcionan por dentro. Con mi clase “Coche” podré realizar todas las operaciones asociadas a un Coche, es decir, Arrancar, Aparcar, Acelerar, Frenar, PonerFrenodeMano, BajarVentanilla, y podré acceder además a otra información como NumeroDePuertas, VelocidadActual, KilometrosRecorridos, Consumo, Marca, Modelo, Conductor…
Si necesito crear una aplicación que a partir de una ruta por una carretera calcule el consumo de diferentes modelos de coche dependiendo de su velocidad media y de si tiene las ventanillas bajadas, no tendría más que utilizar dos de mis clases Coche y Ruta de la siguiente manera.
// Definimos modelo de coche, abrimos la puerta
Coche.Modelo(Seat.SeisCientos);
Coche.AbrirPuerta();
// Creamos una nueva ruta a partir de alguna de las que tengamos definidas
Ruta.DefinirRuta(Rutas.Zaragoza-Barcelona-PorAP2);
// Asociamos la ruta al coche, marcamos velocidad, puertas y definimos que el viaje se hará
// con las ventanillas bajadas… arrancamos y ala, a viajar
Coche.EstablecerRuta(Ruta);
Coche.VelocidadMedia = 120;
Coche.NumeroPuertas = 3;
Coche.BajarVentanilla();
Coche.Arrancar();
Coche.RealizarViaje();
// Guardamos los datos asociados al viaje
Coche.AlmacenarDatosConsumo();
Como podemos ver la protección y la encapsulación es máxima. Sabemos que para poder realizar un viaje primero hay que arrancar el coche, pero no sabemos si el arrancar el coche guardará en alguna tabla alguna información al respecto. Por supuesto no sabemos cómo se realiza el cálculo del consumo de carburante respecto a la velocidad media, ruta y estado de las ventanillas… llamando a “RealizarViaje” se calculará todo. Y lo que es más importante, se habrá consultado información sobre la ruta, modelo del coche… tal vez entren en juego 5, 6 o 20 tablas, pero a nosotros nos trae sin cuidado. Y finalmente, a la hora de almacenar los datos de consumo, tal vez tengamos un histórico de consumos asociados al coche, a la ruta… no lo sabemos, de eso se encargará la clase.
¿Por cierto, quién nos asegura que la información se esté guardando en una base de datos relacional? ¿tal vez se esté llevando acabo en un excel, o en un fichero plano separado por comas… o en una mysql, en un sql server o un oracle? ¿Es necesario si quiera que el desarrollador sepa qué es una select o un insert o un update?
Nuestro modelo de datos está 100% protegido a modificaciones llevadas de forma incorrecta.
Y en cuanto a la seguridad, podríamos dar acceso a un modelo de negocio a una tercera empresa para que se encargara del desarrollo de la aplicación, pero sin mostrarle realmente lo que hay detrás (¿en una dll, en un servicio web?)
Y en cuanto a la motivación del equipo de desarrollo, siguiendo esta forma de desarrollo, ¿quién siente realmente que está moviendo al coche? ¿todos?
Saludos.
Miguel.