Мне нужен способ входа почти в каждый класс в моем приложении.
Подумай еще раз. Если вы думаете, что вам нужно входить почти в каждый класс, что-то не так с вашим дизайном. В этом ответе на Stackoverflow рассказывается о том, что может быть не так с вашим дизайном. Ответ на него дан в контексте .NET, но ответ применим и к Java.
В этом ответе в основном говорится о ведении журнала исключений, для ведения журнала без исключений я бы сказал: предотвращайте регистрацию слишком большого количества информации в слишком многих местах. Для каждой информации или предупреждения, которые вы хотите зарегистрировать, сначала спросите, не должно ли это быть исключением. Например, не записывайте в журнал такие вещи, как «нас не должно быть в этой ветке», а генерируйте исключение!
И даже если вы захотите записать в журнал отладочную информацию, кто-нибудь когда-нибудь это прочитает? В итоге вы получите файлы журнала с тысячами и тысячами строк, которые никто не прочитает. И если они его прочитают, им придется пройти через все эти строки текста и выполнить сложный поиск по регулярным выражениям, чтобы получить информацию, которую они искали.
Еще одна причина, по которой, как я вижу, разработчики делают это, заключается в том, чтобы скрыть свой плохой код. Так же, как и комментарии. Я вижу, как разработчики регистрируют такие вещи, как «мы выполнили этот блок» или «это, если ветвь пропущена». Таким образом они могут отслеживать код и большие методы.
Однако мы все уже знаем, что вместо того, чтобы писать большие методы, методы должны быть небольшими. Нет, даже меньше. Кроме того, если вы тщательно тестируете свой код, нет особых причин для его отладки, и вы убедились, что он выполняет то, что должен делать.
И здесь снова может помочь хороший дизайн. Когда вы используете дизайн, описанный в этом ответе Stackoverflow (с обработчиками команд), вы снова можете создать единственный декоратор, который может сериализовать любое произвольное командное сообщение и записать его на диск до начала выполнения. Это дает вам удивительно точный журнал. Просто добавьте некоторую контекстную информацию (такую как время выполнения и имя пользователя) в журнал, и у вас будет контрольный журнал, который даже можно использовать для воспроизведения команд во время отладки или даже нагрузочного тестирования.
Я использую этот тип дизайна приложения уже пару лет, и с тех пор у меня почти никогда не было причин для дополнительного ведения журнала в рамках бизнес-логики. Это необходимо время от времени, но такие случаи довольно редки.
но это похоже на добавление заботы о ведении журнала к каждому классу и загрязняет мой конструктор
Это так, и вы получите конструкторы со слишком большим количеством параметров. Но не вините регистратора, вините свой код. Вы нарушаете здесь принцип единой ответственности. Вы можете «скрыть» эту зависимость, вызвав ее через статический фасад, но это не снижает количество зависимостей и общую сложность класса.
используя глобальный локатор службы в методе, в котором я хочу вызвать журнал. Но все фанаты DI будут ненавидеть меня за это
В конце концов, вы возненавидите себя за это, потому что каждый класс по-прежнему имеет дополнительную зависимость (в данном случае хорошо скрытую зависимость). Это усложняет каждый класс и заставляет вас иметь больше кода: больше кода для тестирования, больше кода с ошибками, больше кода для обслуживания.
person
Steven
schedule
12.07.2013
ILogger
абстракцию (ту, которая содержит только один член), спрячьте свою структуру ведения журнала за этой абстракцией и внедрите этот интерфейс в классы, которые в нем нуждаются. Это позволяет вам правильно тестировать этот код и скрывает стороннюю зависимость. Взгляните на этот ответ. - person Steven   schedule 12.07.2013