¿Qué patrón de diseño es más adecuado para el registro?

10

Debería registrar algunos eventos en un programa, pero que yo sepa sería mejor mantener el código de registro fuera del programa porque no se trata de la funcionalidad real del programa. Entonces, ¿puede decirme si debo mantenerlo completamente fuera del código y solo usar Observadores y oyentes para registrar los eventos? O puedo agregar una línea de código como la siguiente siempre que necesite registrar algo:

MyGloriousLogger.getXXXLogger().Log(LogPlace, new LogObject(z1, z2, z3, z4, ..., z99));

¿Me equivoco al usar el patrón de diseño de Observer? Necesito otro patrón de diseño? ¿O debería dejar de pensar en patrones de diseño?

PS1 Si deseo iniciar sesión utilizando solo oyentes y observadores, sin duda tendré que agregar y mejorar los observadores y oyentes del programa.

PS2 Ciertamente sé que hay diferentes bibliotecas para iniciar sesión en Java y estoy usando java.utils.logging, pero necesito tener un contenedor para registrar mis objetos especiales.

java design-patterns logging observer-pattern usuario1892555
fuente
2
¿Java ya tiene 17 marcos de registro y marcos de meta-registro (slf4j) y probablemente algún marco de meta-meta-registro y ninguno de ellos funciona para usted?
Kevin Cline

Respuestas:

15

Logginggeneralmente se implementa con el patrón de la Cadena de responsabilidad . Por supuesto que puedes (y lo haría) combinar eso con una Fachada . Realmente no usaría Listener (s) u Observer (s) yo mismo.

Cadena de responsabilidad - Logger

Elliott Frisch
fuente
¿Esto es básicamente decir "escriba en su registrador abstracto en su código"? Supongo que mi pregunta es: ¿debería activar eventos desde donde quiero iniciar sesión y proporcionar un oyente que inicie sesión en respuesta a los eventos, o debería llamar directamente a mi servicio Logger (que utiliza la cadena de responsabilidad internamente) y eso es todo?
Fire-Dragon-DoL
8

Use la Programación Orientada a Aspectos que usa consejos de Después, Antes y Alrededor sobre los métodos. Allí, según su necesidad, puede agregar registros antes del inicio de la API, después o en algunas condiciones y también separar su código principal del código de registro.

Yogesh Patil
fuente
0

Bueno, Observer no me parece apto. Además, lanzar llamadas de registrador "donde sea que lo necesite" romperá su código y violará el SRP.

Puede, por ejemplo, estar interesado en AOP para esto, por lo que puede adjuntar llamadas de registrador a través de anotaciones de método.

Powerslave
fuente
0

La cadena de responsabilidad parece ser un buen patrón cuando su producción puede aterrizar en varios lugares. En el UML tiene un registrador diferente, uno que dirige a la consola, otro al errorFile y el tercero simplemente registrador de información.

Por lo general, he visto que logLevels son diferentes, pero el archivo de registro es el mismo.

No veo el patrón de observador tan malo para el registro, ya que desacopla el código de registro del código de la aplicación. Lo cual es una buena práctica, migrar a diferentes mecanismos de registro es fácil de esta manera. Cada vez que desee iniciar sesión, active un evento y el oyente apropiado lo recibirá y lo registrará. Debe haber un objeto singleton intermedio que contenga la lista de todos los registros.

De esta manera veo que podemos desacoplar nuestro código de registro del código de la aplicación.

usuario2922188
fuente