Стоит ли оборачивать каркас логирования в дополнительный слой?

Question

В настоящее время я смотрю на обновление механизма ведения журналов в кодовой базе Java среднего и большого размера. В настоящее время сообщения регистрируются с использованием статических методов в классе Debug, и я рекомендовал переключиться с этого на что-то вроде SLF4J или commons-logging.

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

Мне это кажется излишним, поскольку SLF4J уже абстрагирует конкретную реализацию логирования.

Стоит ли оборачивать стороннюю журналируемую абстракцию, такую ​​как SLF4J, в другую доморощенную абстракцию?

Answer 1

Я полностью с тобой согласен: обертки от оберток обертки выходят из-под контроля. Я подозреваю, что архитектор не понимает, как SLF4J, в частности, может легко обернуть любую другую систему ведения журналов, так что «изменение реализации» вполне осуществимо без еще одного слоя оболочки.

Answer 2

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

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

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

Тема также обсуждается в разделе SLF4J FAQ .

Answer 3

Я бы предпочел обернуть его, но не по заявленной причине. Если проблема заключается в возможности обмена на другую платформу, используйте java.util.logging или SLF (java.util.logging не так легко использовать, как обертку, но это вполне выполнимо), и поменяйте местами. Причиной использования (еще одной) обертки является кодификация в коде подходящего способа ведения журнала. Как правило, приложению требуется подмножество, например, все системные ошибки, связанные с исключением, или конкретные указания относительно того, когда следует использовать стандартные уровни ведения журнала. Эти решения могут быть заключены в несколько методов, создавая более согласованные решения по ведению журнала в большой кодовой базе.

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

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

Answer 4

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

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

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

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

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

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

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

Делайте резервные копии, хотя ...;)

См. Также Должны ли новые проекты использовать logback вместо log4j? , Что случилось с ведением журнала в Java? , Какой фасад log4j выбрать? , Найдите путь в сцене java logging frameworks. и Считаете ли вы java.util.logging достаточным? . (Спойлер: Вы не должны использовать java.util.logging, пожалуйста)

Answer 5

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

Answer 6

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

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