Стоит ли обертывать фреймворк в дополнительном слое?

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

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

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

Стоит ли обертывать абстракцию сторонней регистрации как SLF4J в другой самодельной абстракции?

Ответ 1

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

Ответ 2

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

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

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

Тема также обсуждается в странице часто задаваемых вопросов SLF4J.

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

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

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

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

Ответ 6

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

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