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

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?

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.

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.

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.