Действительно ли стоит перенести платформу журналирования в дополнительный слой?

Я предполагаю, что желание архитектора обернуть оболочку (например, SLF4J) мотивировало желание изолировать ваше приложение от SLF4J. Очевидно, что вызов SLF4J API из вашего приложения создает зависимость от SLF4J. Однако в равной степени правомерно желание многократно применять принцип изоляции, как обсуждается ниже. Это напоминает мне вопрос Ричарда Докинза: если Бог создал вселенную, то кто создал Бога?

Действительно, вы также можете применить принцип изоляции к оболочке, которая обертывает SLF4J. Причина изоляции была бы неудачной, если бы SLF4J-обертка чем-то уступала SLF4J. Хотя возможно, обертка довольно редко может сравниться или превзойти оригинал. SWT можно привести как достойный внимания контрпример. Однако SWT - масштабный проект со значительной стоимостью. Более того, SLF4J-обертка по определению зависит от SLF4J. У него обязательно должен быть тот же общий API. Если в будущем появится новый и существенно отличающийся API журналирования, код, использующий оболочку, будет так же сложно перенести на новый API, как и код, который напрямую использовал SLF4J. Таким образом, оболочка вряд ли защитит ваш код в будущем, но только усложнит его, добавив дополнительное косвенное обращение.

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

Эта тема также поднимается в Запись в FAQ по SLF4J .

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

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

Эта тема также поднимается в Запись в FAQ по SLF4J .

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

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

Эта тема также поднимается в Запись в FAQ по SLF4J .

Проблема с каждой оболочкой - это решение о том, как вы на самом деле оборачиваете и какие функции вы будете предоставлять:

• commons.logging предоставляет минимальный набор функций ведения журнала, скрываясь дополнительные функции, которые может предоставить базовая платформа. Вы не получите расширенных функций, таких как параметризованное ведение журнала или MDC.
• SLF4J работает наоборот. Он обрабатывает расширенные функции, такие как параметризованное ведение журнала, реализуя их поверх фреймворков, которые не реализуют их изначально. Это лучший способ, IMHO.

Я не знаю ваш текущий класс Debug, но думаю, что он довольно простой.

У вас, вероятно, не будет таких функций, как

• расположение сообщения журнала, т.е. имя исходного файла + номер строки
• разные уровни ведения журнала
• возможность выборочно устанавливать уровень различных средств ведения журнала, т.е. у вас нет одного регистратора на класс, имея возможность установить этот регистратор на определенный уровень представляющих интерес, например ИНФОРМАЦИЯ, ПРЕДУПРЕЖДЕНИЕ. Это очень важно.

Если ваш класс Debug довольно простой , это на самом деле очень хорошо для вас :)

Это означает, что вы, вероятно, сможете переключиться на SLF4J, выполнив глобальный поиск & destr ... err ... replace.

Хотя делайте резервные копии ...;)

См. также Должны ли новые проекты использовать логбэк вместо log4j? , Что там с логированием в Java? , Какой фасад log4j выбрать? , Найдите путь в сцене фреймворков логирования Java. и Считаете ли вы достаточно java.util.logging? .

Объясните своему архитектурному астронавту , что slf4j уже может действовать как оболочка для других реализаций журналирования, таких как log4j. Так что, если вам понадобится использовать какой-то другой регистратор в будущем, и для slf4j нет адаптера, вы можете написать его, когда возникнет необходимость, но это будет просто адаптер, вместо того, чтобы писать целую структуру ведения журнала, которая просто обернет какой-то другой фреймворк журналирования, и вам нужно спроектировать для этого свою структуру и написать собственный адаптер.

I would prefer to wrap it, but not for the stated reason. If the concern is the ability to swap out for another framework, use java.util.logging or SLF (java.util.logging isn't as easy to use as a wrapper, but it is quite doable), and swap away. The reason to use (yet another) wrapper is to codify in code the appropriate way of logging. Generally an application wants a subset, such as all system errors come with an exception, or have specific guidance about when to use the standard logging levels. Those decisions can be encapsulated in a few methods creating more consistent logging decisions over a large code base.

If, however, the motivation is just to make it possible to swap out implementations, don't reinvent the wheel. SLF is perfect for the job, just use it.

There is one exception to this. If your code is meant to be deployed into many possible app servers seemlessly, you do have to make sure that your logging choice doesn't risk conflicting with potentially older or newer versions of whatever the framework is using.

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

Если ваша текущая установка позволяет гибкость изменяться, вы не можете нужна обертка.