로깅에 더 적합한 디자인 패턴은 무엇입니까?

프로그램에 일부 이벤트를 기록해야하지만, 프로그램의 실제 기능에 관한 것이 아니기 때문에 로깅 코드를 프로그램 외부에 유지하는 것이 좋습니다. 코드에서 완전히 제외하고 이벤트와 로그를 기록하는 데 Observers와 Listeners 만 사용해야하는지 말씀해 주시겠습니까? 또는 무언가를 기록해야 할 때마다 다음과 같은 코드를 추가 할 수 있습니다.

MyGloriousLogger.getXXXLogger().Log(LogPlace, new LogObject(z1, z2, z3, z4, ..., z99));

옵저버 디자인 패턴을 잘못 사용합니까? 다른 디자인 패턴이 필요합니까? 아니면 디자인 패턴에 대한 생각을 중단해야합니까?

PS1. 리스너와 옵저버 만 사용하여 로그하려면 프로그램의 옵저버와 리스너를 추가하고 개선해야합니다.

PS2. Java에 로깅하기위한 다른 라이브러리가 있으며 java.utils.logging을 사용하고 있지만 특수 객체를 기록하려면 래퍼가 있어야합니다.

Logging일반적으로 책임 사슬 패턴 으로 구현됩니다 . 물론 당신은 그것을 Facade 와 결합 할 수 있습니다 . 나는 정말로 리스너 또는 옵저버를 사용하지 않을 것입니다.

메소드에 대한 After, Before 및 Around 조언을 사용하는 Aspect Oriented Programming 을 사용 하십시오 . 필요에 따라 api를 시작하기 전, 일부 또는 이후에 로그를 추가하고 기본 코드와 로깅 코드를 분리 할 수 ​​있습니다.

관찰자는 나에게 부적절하게 들린다. 또한 로거 콜을 "필요할 때마다"던지면 코드가 깨져 SRP를 위반하게됩니다.

예를 들어이를 위해 AOP에 관심이있을 수 있으므로 메소드 어노테이션을 통해 로거 호출을 첨부 할 수 있습니다.

출력이 여러 장소에 도달 할 수있는 경우 책임 사슬은 좋은 패턴으로 보입니다. UML에는 콘솔로 향하는 다른 로거 하나가 있으며, 다른 하나는 errorFile 및 세 번째는 단순히 정보 로거입니다.

일반적으로 logLevels는 다르지만 로깅 파일은 동일합니다.

관찰자 패턴이 로깅 코드를 응용 프로그램 코드에서 분리하기 때문에 로깅에 나쁜 것으로 보지 않습니다. 다른 방법으로 다른 로깅 메커니즘으로 마이그레이션하는 것이 좋은 방법입니다. 기록 할 때마다 이벤트를 발생 시키면 해당 리스너가 이벤트를 수신하여 기록합니다. 모든 레지스터 목록을 보유하는 중간 싱글 톤 객체가 있어야합니다.

이 방법으로 로깅 코드를 응용 프로그램 코드에서 분리 할 수 ​​있습니다.