En esta entrada quiero hablar de temas que pocos Para nadie es un secreto la fama y la gran cuota de mercado de las aplicaciones J2EE desarrolladas con Spring Framework sin embargo, a pesar de que Spring guia y facilita el desarrollo de componentes en diferentes capas de una aplicación J2EE haciendo uso de buenas practicas de programación, pocos desarrolladores advierten que en muchos casos (de forma accidental por supuesto) se escribe código que rompe los principios de buenas practicas en desarrollo de Software, todos hemos caido esto y muchas veces creemos de forma errada que al usar técnicas orientadas a patrones de diseño como Inversion Of Control (IoC) tenemos una aplicación funcional y programaticamente "correcta" pero... no es así.
Ahora la pregunta es, por que? antes de comenzar con cualquier proyecto de Software y desde la etapa de análisis y diseño se deberia considerar los 3 siguientes principios y tratar de responder las 3 siguientes preguntas:
[+/-] Continuar leyendo...
Ahora la pregunta es, por que? antes de comenzar con cualquier proyecto de Software y desde la etapa de análisis y diseño se deberia considerar los 3 siguientes principios y tratar de responder las 3 siguientes preguntas:
- os componentes de Software son rigidos? es decir, cambiar fragmentos de código es dificil debido a que puede afectar considerablemente de forma negativa otros componentes del sistema?
- El sistema es fragil? es decir, cambiar fragmentos de código puede producir efectos negativos inesperados en otras partes del sistema?
- Los componentes de Software no son reutilizables? es decir, un componente determinado de software puede ser reutilizado en otro sistema.
Seguramente quien tenga un poco de experiencia en el campo de desarrollo de Software, se ha visto respondiendo de forma desfavorable a una o muchas de estas preguntas (que en realidad son principios ampliamente aceptados en el mundo del desarrollo de software en todo el mundo), Aunque se encuentre usando Spring y sea uno de los frameworks probablemente mas amplios en el mundo de software basado en Java actualmente, los frameworks no convierten un "mal código" en un "buen código", ahora bien, para estos problemas tan comunes existen respuestas que son tambien comunes y se definen basicamente en 2 principios de diseño que son VITALES y que ningun arquitecto de software debera olvidad nunca:
- Los modulos de alto nivel no deben depender directamente de los modulos de bajo nivel, ambos deben depeder de abstracciones, o definiciones comunes.
- Las abstracciones no deben depender de los detalles espeficios de las implementaciones, por el contrario las implementaciones deben depender de las abstracciones.
Por lo que hemos visto anteriormente, cobra sentido el uso de clases abstractas e interfaces como una buena practica en desarrollo de software Orientado a Objetos, algo que comunmente realizan los desarrolladores sin conocimiento de causa, y solamente lo hacen por que lo han visto en un tutorial de Spring y "así les funciona" pero todo en el mundo del Software tiene su causa y su(s) efecto(s), nuestra tarea es conocer las causas y posibles efectos.
Es muy importante tener muy presente que, la Inyección de Dependencia en Java es normalmente conocida bajo el concepto de Factoria la cual instancia objetos e inyecta otros que dependen de ellos para ser utilizados en una aplicación, ahora bien, cuando usamos Spring tenemos una ventaja importante de la que por desgracia no tenemos con el uso con otras especificaciones tan comunes y potentes como EJB y es el testing y la administración de la construcción/destrucción de los Beans Out of Box, esto en realidad lo que quiere decir es que el contenedor IoC de Spring desarrolla todas estas tareas (y mas) de una forma autonoma e independiente del contenedor J2EE subyacente, por lo tanto podemos ejecutar Spring sin necesitar de forma obligatoria un contenedor J2EE, lo cual es tipico en este tipo aplicaciones me refiero efectivamente a que es normal que sea necesario un contenedor y busquedas JNDI para encontrar Factorias o recursos, pero con Spring, esto no es necesariamente obligatorio.
Otro tema un poco a nivel de diseño, (pero que es aun muy importante a nivel de arquitectura) es el uso de adecuado de una nomenclatura estandar para tareas comunes, Vamos a declarar un escenario frecuente: "Llamo en un Objeto de acceso a datos con un metodo llamado guardarAlgoX() y luego tengo otro tiene un metodo llamado insertarAlgoY(), y ambos metodos realizan una inserción comun en base de datos" Ahora bien, existe un concepto muy importante que es Programación Orientada a Aspectos (AOP) mas que un concepto, es un modelo de programación diferente al modelo clasico orientado a objetos, no entraré en mayores detalles, basta con decir que (AOP) nos brinda flexibilidad adicional que no disponemos con la POO, esto debido a la introducción de conceptos como Aspectos, Puntos de Corte, etc. Necesario anotar que AOP no es una "sustitución" del modelo OO por el contrario se trata de un modelo adicional complementario y es justo aquí en el momento en el que Spring entra en acción, en la situación anterior, lo normal deberia ser definir una nomenclatura "estandar" donde los nombres de los métodos contengan nombres auto-explicativos deacuerdo a las operaciones que realizan como "guardar", "buscar" "eliminar", etc. por ejemplo en el caso anterior, los metodos deberian nombrarse de una forma similar a: guardarAlgoX(), guardarAlgoY() de este modo es mucho mas simple manejar temas complejos como transacciones y auditorias, dado que se pueden insertar puntos de corte para "monitorizar" determinadas acciones en los metodos que comienzan o contienen una cadena determinada como por ejemplo "eliminar", "insertar", etc. Pequeños detalles que muchas veces por inexperiencia, desconocimiento o simplemente descuido nos hacen tener un código con errores, dificil de mantener, y mucho mas dificil de modificar o extender.
Bien, una entrada corta, que espero que os haga reflexionar un poco en el modo en el cual hacemos las cosas....
Jdaanial.
Es muy importante tener muy presente que, la Inyección de Dependencia en Java es normalmente conocida bajo el concepto de Factoria la cual instancia objetos e inyecta otros que dependen de ellos para ser utilizados en una aplicación, ahora bien, cuando usamos Spring tenemos una ventaja importante de la que por desgracia no tenemos con el uso con otras especificaciones tan comunes y potentes como EJB y es el testing y la administración de la construcción/destrucción de los Beans Out of Box, esto en realidad lo que quiere decir es que el contenedor IoC de Spring desarrolla todas estas tareas (y mas) de una forma autonoma e independiente del contenedor J2EE subyacente, por lo tanto podemos ejecutar Spring sin necesitar de forma obligatoria un contenedor J2EE, lo cual es tipico en este tipo aplicaciones me refiero efectivamente a que es normal que sea necesario un contenedor y busquedas JNDI para encontrar Factorias o recursos, pero con Spring, esto no es necesariamente obligatorio.
Otro tema un poco a nivel de diseño, (pero que es aun muy importante a nivel de arquitectura) es el uso de adecuado de una nomenclatura estandar para tareas comunes, Vamos a declarar un escenario frecuente: "Llamo en un Objeto de acceso a datos con un metodo llamado guardarAlgoX() y luego tengo otro tiene un metodo llamado insertarAlgoY(), y ambos metodos realizan una inserción comun en base de datos" Ahora bien, existe un concepto muy importante que es Programación Orientada a Aspectos (AOP) mas que un concepto, es un modelo de programación diferente al modelo clasico orientado a objetos, no entraré en mayores detalles, basta con decir que (AOP) nos brinda flexibilidad adicional que no disponemos con la POO, esto debido a la introducción de conceptos como Aspectos, Puntos de Corte, etc. Necesario anotar que AOP no es una "sustitución" del modelo OO por el contrario se trata de un modelo adicional complementario y es justo aquí en el momento en el que Spring entra en acción, en la situación anterior, lo normal deberia ser definir una nomenclatura "estandar" donde los nombres de los métodos contengan nombres auto-explicativos deacuerdo a las operaciones que realizan como "guardar", "buscar" "eliminar", etc. por ejemplo en el caso anterior, los metodos deberian nombrarse de una forma similar a: guardarAlgoX(), guardarAlgoY() de este modo es mucho mas simple manejar temas complejos como transacciones y auditorias, dado que se pueden insertar puntos de corte para "monitorizar" determinadas acciones en los metodos que comienzan o contienen una cadena determinada como por ejemplo "eliminar", "insertar", etc. Pequeños detalles que muchas veces por inexperiencia, desconocimiento o simplemente descuido nos hacen tener un código con errores, dificil de mantener, y mucho mas dificil de modificar o extender.
Bien, una entrada corta, que espero que os haga reflexionar un poco en el modo en el cual hacemos las cosas....
Jdaanial.
No hay comentarios:
Publicar un comentario