2021.10.31 TIL

pbg0205·2021년 10월 31일
0

TIL

목록 보기
3/13

김영한님 스프링 핵심원리 고급편 참고 내용

핵심기능 vs 부가 기능

  • 핵심 기능 : 해당 객체가 제공하는 고유의 기능
    • ex) orderService.orderItem(), orderRepository.save(itemId)
  • 부가 기능 : 핵심 기능 보조하기 위해 제공
    • ex) 로그 추적 로직, 트랜잭션 기능



변하는 것과 변하지 않는 것을 분리

  • 템플릿 메서드 패턴(Tempate Method Pattern)
    • 템플릿이라는 틀에 변하지 않는 부분을 몰아두고 변하는 부분을 별도로 호출해서 해결한다. (템플릿 안에 변하는 부분은 call()메서드를 호출해서 사용한다.)
      • 변하는 부분 → ex) 비즈니스 로직
      • 변하지 않는 부분 → ex) 시간 로직
@Slf4j
public abstract class AbstractTemplate {
		
	public void execute() {
		long startTime = System.currentTimeMills();
				
		//비즈니스 로직 실행
		call(); //상속
		//비스니스 로직 종료
		
		long endTime = System.currenTimeMills();

		long resultTime = endTime - startTime();
		log.info("resultTime={}", resultTime);
	}

	protected abstract void call();
}

public SubClassLogic1 extends AbstractTemplate {
	@Override
	protected void call() {
		log.info("비즈니스 로직1 실행");
	}
}

public SubClassLogic2 extends AbstractTemplate {
	@Override
	protected voic call() {
		log.info("비즈니스 로직2 실행");
	}
}

적용 코드

//OrderControllerV4

public String request(String itemId) {
	AbstractTempate<String> template = new AbstractTemplate<>(trace) {
		@Override
		protected String call() {
			orderService.orderItem(itemId);
			return "ok";
		}
	};

	template.execute("orderController.request()");
}

좋은 설계란?

  • 좋은 설계는 변경이 일어날 때 확인할 수 있다.
  • 단일 책임 원칙(SRP) : 로그를 남기는 부분을 모듈화하고, 비즈니스를 분리했다. 명확한 역할 분리는 변경에 쉽게 대처할 수 있다.

하지만 템플릿 메서드 패턴도 단점이 존재한다.

  • 템플릿 메서드 패턴상속을 사용한다. 상속 관계는 강한 의존 관계를 형성한다.
  • 현재 상황에서 자식 클래스는 부모 클래스의 기능을 전혀 사용하지 않는다. 이 때 상속을 사용하는 것은 바람직한 설계가 아니다.
  • 그리고 이러한 상속 구조는 클래스가 익명 내부 클래스를 만들어야 해서 복잡해진다.
  • 이를 개선할 수 있는 방법이 전략 패턴(strategy pattern)이다.

profile
🧑‍💻 steady developer

0개의 댓글