📕 Backend

이 전 포스팅에서 알아본 Template Method Pattern은 "추상 클래스"에 자식 클래스에서 변경되는 로직의 골격을 선언 및 공통으로 사용하는 로직의 골격을 정의(*구현)하고 "자식 클래스"에서는 부모 클래스를 상속받아 변경되는 로직을 정의(*구현)하는 방식이였습니다. 이 패턴에서는 상속을 사용하여 "특정" 부모 클래스에 의존하지만, 아래 코드와 같이 자식 클래스 입장에서 '구현 클래스'만 딱 생각해보면 부모 클래스의 기능을 전혀 사용하지도 않는데, 부모 클래스의 영향을 받게 됩니다. @Slf4j public class SubClassLogic1 extends AbstractTemplate { @Override protected void call() { log.info("비즈니스 로직1 실행"..

로그 추적기에 ThreadLocal을 도입해서 파라미터를 넘기는 불편함을 제거했습니다. 이번에는 로그 추적기에 여러 템플릿 메소드 패턴을 적용시켜 비즈니스 로직에서 핵심 기능과 부가 기능인 로그 기능을 분리해봅시다. "핵심 기능" 해당 객체가 제공하는 고유의 기능을 말합니다. 예를 들면 OrderService의 orderItem()의 핵심 기능은 주문 로직입니다. OrderService의 orderItem()의 주문 로직 : orderRepository의 save()를 호출하여 주문을 저장 "부가 기능" 핵심 기능을 보조하기 위해 제공되는 기능 예를 들면 OrderService의 orderItem()의 부가 기능은 로그 추적 로직, 트랜잭션 기능 아래 코드를 보면 부가 기능과 핵심 기능이 하나의 메소드에..

이 전 포스팅에서 파라미터 동기화로 하나의 HTTP 요청에 대해서 고유의 TraceId를 사용하도록 고쳐보았습니다.동기화에는 성공했지만, 여전히 문제가 있었습니다. 로그를 출력하는 모든 메소드에 TraceId 파라미터를 추가해주어야 하는 껄끄러움(확장, 유지보수에 대한 불편함)이 있었습니다.뿐만 아니라 각 계층에 try/catch문을 사용하게 되어 코드의 가독성까지 떨어졌어요.이 외에도 첫 요청에 대해서만 begin을 호출하고, 이어받은 계층에서는 beginSync를 실행하도록 설정해야 하기 때문에, 비슷한 기능에 코드의 확장까지 이루어져 좋은 코드라고 보기 어렵습니다.이번에는 다른방법을 도입해보도록 합시다. 결론적으로 말하자면 ThreadLocal을 사용합니다. 하지만 처음부터 ThreadLocal을 ..

로그 추적기를 만들어 보면서 스프링 핵심원리에 대해 조금 더 깊게 배워봅시다. 요구사항 public 메소드의 호출에 대한 응답 정보 로그 출력 비즈니스 로직의 동작에 영향을 주지 않게. 메소드 호출에 걸린 시간도 함께 출력 정상 흐름, 예외 흐름 구분 - 예외 발생 시 예외 정보 출력 메소드 호출의 깊이 표현 : level이 증가 할수록 깊이를 직관적으로 표현 HTTP 요청 구분 : HTTP 요청 단위로 특정 ID를 남겨서 Client를 구분 하나의 HTTP 요청의 시작과 끝을 하나의 ID로 묶도록 예시 로그를 적용할 단순 로직 생성 추후 로그생성기를 만들고 적용해볼 로직을 간단하게 만들어주었습니다. 코드에 대한 설명은 생략하도록 하겠습니다. 로그에 대한 정보를 저장할 객체 생성 - TraceId - (..

함수형 인터페이스 - @FunctionalInterface 단 하나의 추상 메소드만 선언된 인터페이스 interface MyFunction { public abstract int max(int a, int b); } MyFunction f = new MyFunction(){ public int max(int a, int b){ return a > b ? a : b; } }; 위처럼 인터페이스에 추상메소드로 선언해두면 람다식으로 운영또한 가능합니다. MyInterface f = (int a, int b) -> a > b ? a : b; int big = f.max(5, 3); 이처럼 MyInterface 인터페이스를 구현한 익명 객체를 람다식으로 대체가 가능한 이유는, 람다식은 실제로는 익명 객체이고, M..