design-patterns - gof - visitor design pattern java
Ejemplo de preocupación transversal (3)
Además de la respuesta aceptada, quiero mencionar otro ejemplo para una preocupación transversal: la comunicación remota. Digamos que solo quiero llamar a otros componentes de mi ecosistema localmente como si estuvieran en proceso. Quizás en algunos casos incluso lo hacen. Pero ahora quiero ejecutar mis servicios distribuidos en una nube o clúster. ¿Por qué debería importarme este aspecto como desarrollador de aplicaciones? Un aspecto podría ocuparse de averiguar a quién llamar y cómo, serializar los datos transmitidos si es necesario y realizar una llamada remota. Si todo se estuviera ejecutando, el aspecto simplemente reenviará la llamada local. En el lado de llamada, el aspecto deserializaría los datos, realizaría la llamada local y devolvería el resultado.
Ahora déjame contarte una pequeña historia sobre cosas "triviales" como la salida de registro: hace solo unas semanas reformé una base de código compleja, pero no demasiado grande (alrededor de 250,000 líneas de código) para un cliente. En unas pocas centenas de clases se utilizó un tipo de marco de trabajo de registro, en otro centenar de otros. Luego hubo varios miles de líneas de System.out.println(*) donde realmente debería haber estado la salida de registro. Así que terminé arreglando miles de líneas de código dispersas en la base de códigos. Afortunadamente, podría usar algunos trucos ingeniosos en IntelliJ IDEA (búsqueda y reemplazo estructural) para acelerar toda la acción, pero ¡no creas que fue trivial! Seguro, el registro de depuración fuertemente dependiente del contexto siempre ocurrirá dentro de un cuerpo de método, pero muchos tipos importantes de registro, como las llamadas al método de rastreo (incluso jerárquicamente con un resultado muy sangrado), el registro de excepciones administradas o no, la auditoría del usuario (registro de llamadas a métodos restringidos basados en roles de usuario) y así sucesivamente pueden implementarse fácilmente en aspectos sin que contaminen el código fuente. El desarrollador de aplicaciones cotidianas no necesita pensar en ello ni siquiera ver las llamadas de registrador dispersas por la base de códigos. Alguien es responsable de mantener el aspecto actualizado e incluso puede cambiar la estrategia de registro o el marco de registro completo centralmente en un solo lugar.
Puedo encontrar explicaciones similares para otras preocupaciones transversales. Mantener el código limpio y libre de la dispersión y el enredo de la OMI es una cuestión de profesionalismo, no nada opcional. Por último, pero no por ello menos importante, mantiene el código legible, mantenible y refactorizable. Amén.
¿Cuál es un buen ejemplo de una cross-cutting concern ? El ejemplo de registro médico en la página de wikipedia me parece incompleto.
Específicamente a partir de este ejemplo, ¿por qué el registro llevaría a la duplicación de código ( dispersión )? (Además de llamadas simples como log("....") todas partes, lo que no parece ser un gran problema).
¿Cuál es la diferencia entre una core concern y una cross-cutting concern ?
Mi objetivo final es obtener una mejor comprensión de AOP.
Antes de entender la Preocupación Transversal , tenemos que entender la Preocupación .
Una preocupación es un término que se refiere a una parte del sistema dividida en función de la funcionalidad.
Las preocupaciones son de dos tipos:
- Las preocupaciones que representan la funcionalidad única y específica para los requisitos primarios se conocen como preocupaciones centrales .
O
La función primaria del sistema se conoce como preocupaciones centrales.
Por ejemplo : lógica de negocios - Las preocupaciones que representan funcionalidades para requisitos secundarios se conocen como preocupaciones transversales o preocupaciones de todo el sistema .
O
La preocupación transversal es una preocupación que se aplica a lo largo de la aplicación y afecta a toda la aplicación.
Por ejemplo: el registro, la seguridad y la transferencia de datos son las preocupaciones que se necesitan en casi todos los módulos de una aplicación, por lo que son preocupaciones transversales.
Esta figura representa una aplicación típica que se divide en módulos. La preocupación principal de cada módulo es proporcionar servicios para su dominio particular. Sin embargo, cada uno de estos módulos también requiere funcionalidades auxiliares similares, como el registro de seguridad y la gestión de transacciones. Un ejemplo de problemas transversales es el "registro", que se utiliza con frecuencia en aplicaciones distribuidas para ayudar a la eliminación de errores mediante llamadas al método de rastreo. Supongamos que registramos tanto al principio como al final de cada cuerpo de función. Esto dará como resultado el corte transversal de todas las clases que tienen al menos una función.
Creo que el único mejor ejemplo de una preocupación transversal es el comportamiento transaccional. Tener que poner bloques try-catch con llamadas commit y rollback en todos sus métodos de servicio sería repelente, por ejemplo. Anotar los métodos con un marcador que AOP puede usar para encapsularlos con el comportamiento transaccional deseado es una gran ganancia.
Otro buen candidato como ejemplo de una preocupación transversal es la autorización. Anotar un método de servicio con un marcador que indique quién puede llamarlo, y dejar que algunos consejos de AOP decidan si se permite o no la llamada al método, puede ser preferible a manejar ese código en el método de servicio.
Implementar el registro con el asesoramiento de AOP podría ser una forma de obtener más flexibilidad, para que pueda cambiar lo que se registra cambiando un punto de unión. En la práctica, no veo proyectos que lo hagan muy a menudo. Por lo general, usar una biblioteca como log4j que le permite filtrar por nivel de registro y categoría, en el tiempo de ejecución si es necesario, funciona bastante bien.
Una preocupación central es la razón por la que existe la aplicación, la lógica comercial que la aplicación automatiza. Si tiene una aplicación de logística que maneja la carga de envío, averiguar cuánto carga puede empacar en un camión o cuál es la mejor ruta para que el camión lleve sus entregas podría ser una preocupación central. Las preocupaciones transversales son típicamente detalles de implementación que deben mantenerse separados de la lógica comercial.