스프링은 EJB의 무겁고 복잡한 플랫폼에서 벗어나 POJO기반의 경량화된 개발 환경을 제공하는 오픈소스 프레임워크

 

좋은 객체 지향 설계의 5가지 원칙(SOLID)

 

SOLID

-SRP : 단일 책임원칙(Single Responsibility Principle)

한클래스는 하나의 책임만 가져야 한다.

중요한 기준은 변경! 변경이 있을때 파급효과 적으면 단일 책침 원칙을 잘 따른것!

 

-OCP: 개방-폐쇄의 원칙(Open/Closed Principle)

소프트웨어 요소는 확장에는 열려있고 변경에는 닫혀있어야 한다.

다형성 활용!

 

-LSP: 리스코프 치환 원칙(Liskov Substitution Principle)

프로그램의 객체는 프로그램의 정확성을 깨지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다

 

-ISP: 인터페이스 분리 원칙(Interface Segregation Principle)

특정 클라이언트를 위한 여러개의 인터페이스가 범용 인터페이스 하나보다 낫다

인터페이스가 명확해지고, 대체 가능성이 높아진다

 

-DIP: 의존관계 역전 원칙(Dependency Inversion Principle)

구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻

역할에 의존하게 해야한다


@Slf4j에 대한 글을 적으려다 비슷한 @Log4j2에 대해서 찾아보게되었다.

@Slf4j는 사용해 보았지만 @Log4j2는 사용해 보질 않아 두가지 모두 정리해보고 싶어 작성하였다.

 

 

1.@Slf4j

 

필자가 사용해본 로깅 라이브러리이며 여러 로깅 프레임워크와의 호환성을 제공하는 추상화 레이어이며 이 추상화 레이어의 interface모음이다. 장점은 다양한 로깅 구현체를 쉽게 교체할 수 있다는 것이다.

 

사용법은

@Slf4j
public class StudyController {
}

와 같이 상단에 선언을 해주면 되고

log.trace("가장 디테일한 로그");
log.warn("경고");
log.info("정보성 로그");
log.debug("디버깅용 로그");
log.error("에러");

각 코드를 상황에 맞게 사용하면 된다

 

로깅 레벨은 (많은 로깅)trace > warn > info > debug > error(적은로깅) 순이다

 

 

2. Log4j2

 

필자가 사용해 보지 못한 로깅 라이브러리이며 개발자가 로깅 메시지를 캡처하고, 필요에 따라 다양한 방법으로 출력하도록 도와준다.

 

사용법은

logger.log(Level.ALL,"LOG TEST");
        logger.trace("TRACE TEST");
        logger.info("INFO TEST");
        logger.debug("DEBUG TEST");
        logger.warn("WARN TEST");
        logger.error("ERROR TEST");
        logger.fatal("FATAL TEST");

 

 

3. 무엇을 더 많이 사용하는가?

 

두 라이브러리 모두 장단점이 있으며 프로젝트의 요구 사항과 개발자의 선호에 따라 선택할 수 있다.

SLF4J를 사용하면 다양한 로깅 구현체를 쉽게 교체할 수 있으므로, 더 넓은 범위의 프로젝트에 적합할 수 있다. 

Log4j2는 향상된 성능과 기능을 제공하므로, 이러한 특성을 활용하려는 프로젝트에서 더 적합할 수 있다.

+ Recent posts