Навіщо створювати об’єкт Logger замість використання методів статичного ведення журналу для програми?

Візьмемо приклад простого додатка Ruby on Rails. Він створює Loggerоб'єкт під час завантаження програми:

# 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."

Моє запитання: чому ми не використовуємо методи класу (або статичні методи) для ведення журналів? Не буде Logger.warnмасштабу, ніж Logger.new.warn? Або щонайменше Logger.warnздається інтуїтивно зрозумілим, ніж Logger.new.warn.

Навіть якщо Logger.newце однотонний об'єкт, які переваги він пропонує?

Ось приклад, який використовує Java. Минув час, коли я використовував log4j, але, як я пам’ятаю, весь інструмент журналу log4j ініціалізувався з XML-файлу. Сам XML-файл може містити кілька реєстраторів з різною конфігурацією (куди ви пишете, які рівні записуються тощо). Отже, у цьому випадку у вас будуть об'єкти реєстратора, а не статичні методи реєстратора, щоб вказати, який реєстратор ви хочете викликати. Тобто

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

записує речі, пов’язані з підключенням до мережі, скинутими пакетами тощо, або

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

які б реєстрували речі, пов'язані з вашою бізнес-логікою / додатком. Принаймні, за допомогою log4j ви також можете налаштувати, які рівні журналів фактично виписані (інформація, трасування, попередження, помилка; налагодження доступні за замовчуванням).

Якщо у вас були статичні методи, найкраще, що ви могли зробити, - це налаштувати єдиний реєстратор, який би вказував на стандартний вихід, файл тощо, але все, що ви записуєте, пішло б на те саме місце. З об’єктами реєстратора це зробити простіше, щоб інформація про ваш журнал була розповсюджена на кілька файлів.

Logger.new - це фабрика, яка візьме місце, де буде використаний результат (назва класу / файлу).

У файлах конфігурації ви зможете вирішити, на якому рівні потрібно увійти, щоб не входити в журнал для частини програми без необхідності перекомпілювати проект.

Таким чином, ви можете вимкнути всі журнали (помилки) на високому рівні для версій версій і активувати лише найнижчий рівень для тих частин, які ви налагоджуєте.

По можливості слід уникати виклику статичного методу, де це можливо. Це старовинна альтернатива правильному введенню залежності, а не те, що вам стане корисним у більшій кодовій базі.

Розглянемо, наприклад, доказовість. За допомогою статичного виклику журналів суб'єкт знаходиться під тестом, під контролем якого класу ведення журналів використовується - немає інверсії управління. Тут немає можливості вводити об'єкт макету або будь-який вид підробки. Ввівши журнал в SUT, ви побачите, що у вас є можливість знущатися з реєстратора та вводити його.

Переваги використання DI над видом статичного методу, що обговорюється, звичайно, виходить за рамки доказовості. Поміркуйте, що станеться, якщо ви хотіли б мати дві різні реєстратори у вашій системі, а також можливість змінити поведінку програми лише через конфігурацію об'єктного графіка, не редагуючи існуючий код.

Загалом, я б запропонував спробувати підхід DI, щоб згодом ви не знайшли свій код нестабільним та громіздким.