SLF4J로 보는 Facade pattern

최근들어 스프링으로 포지션을 고정하고자 기초부터 공부를 하고있습니다. Spring Boot의 공통 로그 모듈인 SLF4J와 실제 구현부가 궁금해 분석해본 내용과 해당 내용을 통해서 이론으로만 접했던 Facade 패턴이 SLF4J에서는 어떻게 적용되어있는지를 포스팅 해보려고 합니다.

 

SLF4J

다음은 위키백과에서 소개하는 SLF4J 입니다.

 

SLF4J ( Simple Logging Facade for Java )는 간단한 파사드 패턴을 통해 Java 로깅 API 를 제공합니다 . 기본 로깅 백엔드는 런타임 에 원하는 바인딩을 클래스 경로 에 추가하여 결정되며 표준 Sun Java 로깅 패키지 java.util.logging, [2] log4j , logback [3] 또는 tinylog 일 수 있습니다.

SLF4J - Wikipedia

사실 로깅을 공부하면서 파사드 패턴이라는 부분이 머리속에서 잘 그려지지 않았습니다. 여기서 제가 이해한 부분은 런타임시에 SLF4J를 제공하는 로깅 패키지 중 하나를 바인딩해서 SLF4J API로 사용한다 정도였죠. 그래서 한번 실제로 어떤식으로 구현되어있는지 보겠습니다.

 

Facade Pattern

 

 

외관 패턴 (또한 철자 외관은 )는 인 소프트웨어 디자인 패턴 일반적으로 사용되는 객체 지향 프로그래밍 . 건축 의 파사드 와 유사하게 파사드는 보다 복잡한 기본 또는 구조적 코드를 마스킹하는 전면 인터페이스 역할을 하는 객체 입니다. 외관은 다음과 같습니다.
https://en.wikipedia.org/wiki/Facade_pattern

Facade pattern - Wikipedia

 

Facade Pattern은 쉽게 얘기해서 복잡한 서브시스템을 하나의 메인시스템으로 제공하는 패턴입니다. 실제 프로젝트에 적용되어 있지만 인식하지 못하고 쓰는 경우도 있답니다.

Facade Pattern은 서비스를 구현한다고 생각하면 됩니다. 우리가 회원가입 이라고하는 서비스를 작성할때 SignUp()이라는 메소드(전면 인터페이스 역할을 하는 메소드)를 실행하면 실제 내부 로직에서는 아이디 중복체크, 회원 테이블 삽입, 회원번호 채번 등의 내부로직이 돌아가게 됩니다. 마치 위의 서비스 구현처럼 여러 서브 시스템을 하나의 인터페이스 역할을 하는 객체를 제공함으로써 복잡성을 줄이고 상호 의존적인 클래스들의 의존성을 낮춰줍니다.

 

SLF4J 분석하기

SLF4J가 Facade Pattern이라고하니 Facade 객체에 해당하는 객체가 존재하겠죠? 전면 인터페이스 역활을 해주는 객체는 바로 Logger 객체입니다. 그덕분에 우리는 SLF4J를 통해서 구현부에 관계없이 해당 소스들로 Logging을 할 수 있습니다.

package com.example.demo;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {

    private static Logger logger = LoggerFactory.getLogger(DemoApplication.class);

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
        logger.info("test");
    }

}

SLF4J 패키지에서 Facade 객체에 해당하는 Logger Interface를 볼 수 있다.

소스상의 Facade 객체는 Logger라고 말씀드렸습니다. SLF4J 패키지를 까보니 Logger에 해당하는 Interface를 제공하는것을 볼 수 있습니다. SLF4J는 실제 구현부가 아닌 로깅 시스템을 공통으로 쓸 수 있도록 구조화해 바인딩과 인터페이스를 제공하는 역활이니 실제 우리가 사용하는 Logger의 구현체는 Logback, Log4J2 등 SLF4J를 지원하는 로깅 패키지에 있습니다.

 

실제 logback 패키지를 까보면 org.slf4j.Logger를 구현한 Logger 객체를 확인 할 수 있다.

실제 사용되는 메소드 구현부를 확인할 수 있다

위의 사진과 같이 실제 소스상에 사용되는 서브시스템에 해당하는 구현부를 확인할 수 있다. 이처럼 SLF4J에서 제공하는 구조화된 Logger 인터페이스를 통해서 구현된 객체를 다형성을 통해서 Logger 객체에 바인딩 해주고 우리는 Logback, Log4J2 등 사용하는 로그 api와 상관없이 하나의 소스로 로깅을 구현할 수 있다.

혹시나 프로젝트에서 라이브러리 변경, 혹은 Util모듈의 변경으로 IDE상에서 찾아서 바꾸기를 사용해본적이 있을것이다. SLF4J와 같이 Facade Pattern을 통해 적시적소에 사용한다면 해당 객체의 의존성을 줄여 소스코드 관리의 장점을 가질 수 있다.

 

평소 Plugin형태의 개발은 어떻게 진행되나 궁금했었는데 Facade Pattern을 이용한다면 내가 생각하는 Plugin형태의 개발을 할 수 있지 않을까 생각된다.

 

참고자료

https://en.wikipedia.org/wiki/SLF4J

SLF4J - Wikipedia

https://en.wikipedia.org/wiki/Facade_pattern

Facade pattern - Wikipedia

https://kimsunzun.tistory.com/entry/Facade-Pattern

Facade Pattern