Зачем создавать объект 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 - это фабрика, которая будет брать то, где будет использоваться результат (имя класса / файла).

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

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

По возможности следует избегать вызова статического метода. Это устаревшая альтернатива правильному внедрению Dependency Injection, и вы не найдете ничего полезного в большей кодовой базе.

Рассмотрим тестируемость, например. Статически активируемое ведение журнала позволяет тестируемому субъекту контролировать, какой класс ведения журнала используется - инверсия управления отсутствует. Здесь нет возможности внедрить фиктивный объект или какую-либо подделку. Вставив регистратор в SUT, вы обнаружите, что у вас есть возможность смоделировать регистратор и внедрить его.

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

В целом, я бы посоветовал вам попробовать подход DI, чтобы потом не найти ваш код непроверенным и громоздким.