¿Por qué crear un objeto Logger en lugar de utilizar métodos de registro estático en una aplicación?

14

Tomando un ejemplo de una aplicación simple de Ruby on Rails. Crea un Loggerobjeto durante el proceso de carga de la aplicación:

# in environment.rb
config.logger = Logger.new(<STDOUT | file | whatever>)

# and in our application we use this object
logger.warn "This process is taking too long to process. Optimization needed."

Mi pregunta es, ¿por qué no usamos métodos de clase (o métodos estáticos) para iniciar sesión? No Logger.warnescalará que Logger.new.warn? O al menos Logger.warnparece intuitivo que Logger.new.warn.

Incluso si Logger.newes un objeto singleton, ¿qué ventajas ofrece?

development-process logging

— Harup Gupta
fuente

17

Aquí hay un ejemplo que usa Java. Ha pasado un tiempo desde que usé log4j, pero por lo que recuerdo, toda la herramienta de registro log4j se inicializaría desde un archivo XML. El archivo XML en sí podría contener múltiples registradores con diferentes configuraciones (dónde escribe, en qué niveles se escribe, etc.). Entonces, en este caso, tendría objetos de registrador en lugar de métodos estáticos de registrador para especificar qué registrador desea invocar. Es decir.

Logger logger = Logger.get("Network");

registraría cosas relacionadas con la conectividad de red, paquetes descartados, etc., o

Logger logger = Logger.get("Application");

que registraría cosas relacionadas con su lógica / aplicación empresarial. Al menos con log4j también puede configurar qué niveles de registro se escriben realmente (los niveles predeterminados disponibles son información, rastreo, advertencia, error, depuración).

Si tuviera métodos estáticos, lo mejor que podría hacer es configurar un único registrador que apunte a la salida estándar, un archivo, etc., pero todo lo que registre iría al mismo lugar. Con los objetos de registro, es más fácil hacerlo para que su información de registro se extienda a múltiples archivos.

— Shaz
fuente

Gracias. Esto también ayudó a comprender cuándo usar métodos estáticos.

— Harsh Gupta

2

Si bien prefiero crear una instancia de un objeto para hacer mi registro, como se demuestra aquí, es bastante común (diría que preferible) acceder a él de forma estática en lugar de pasarlo a cada llamada a un método. El registro es de naturaleza global.

— Chad Schouggins

También es de destacar que hay momentos en los que podríamos querer configurar el registrador extendiéndolo (o proporcionando una implementación de alguna interfaz y proporcionándola al registrador). Esto se utilizaría para hacer algo como cambiar el destino de registro (más allá de lo que los archivos de configuración podrían permitir). Sin embargo, probablemente haría que la instancia específica sea estática, como mencionó @ChadSchouggins.

— Kat

2

Logger.new es una fábrica que llevará a donde se utilizará el resultado (nombre de la clase / archivo).

En los archivos de configuración, puede decidir en qué nivel iniciar sesión para no iniciar sesión en absoluto para partes del programa sin tener que volver a compilar el proyecto.

Por lo tanto, puede deshabilitar todos los registros (errores) excepto los de alto nivel para las versiones de lanzamiento y solo activar el nivel más bajo para las partes que está depurando.

— monstruo de trinquete
fuente

2

La invocación de métodos estáticos debe evitarse siempre que sea posible. Es una alternativa anticuada a la inyección de dependencia adecuada, y no es algo que encuentre útil en una base de código más grande.

Considere la capacidad de prueba, por ejemplo. Invocar estáticamente el registro pone al sujeto bajo prueba en control de qué clase de registro se utiliza: no hay inversión de control. No hay posibilidad de inyectar un objeto simulado o cualquier tipo de falsificación aquí. Al inyectar el registrador en el SUT, encontrará que tiene la opción de burlarse del registrador e inyectarlo.

Los beneficios de usar DI sobre el tipo de invocación de método estático en discusión van más allá de la comprobabilidad, por supuesto. Considere lo que sucedería si desea tener dos registradores diferentes en su sistema y la opción de cambiar el comportamiento de la aplicación a través de la configuración del gráfico de objeto solo, sin editar el código existente.

En general, le sugiero que intente un enfoque DI, para que no encuentre su código inestable y difícil de manejar más adelante.

— Sam Burns
fuente