1. 시스템 제작과 사용을 분리하라.

<aside> 💡 제작(construction)과 사용(use)는 다르다

</aside>

<aside> 💡 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다.

</aside>

10장 클래스와 이어지는 비슷한 내용이다. 먼저 아래 코드를 보자.

public Service getService() {
	if(service == null)
		service = new MyServiceImpl(...);
	return service;
}

위 코드는 초기화 지연(Lazy Initialization) 혹은 계산 지연(Lazy Evaluation)이라는 기법이다.

• 장점
  • 필요할 때까지 객체를 생성하지 않아 과부하를 막는다.
  • 애플리케이션 시작이 그만큼 빨라진다.
  • Null을 반환하지 않는다.
• 단점
  • MyServiceImpl과 생성자 인수에 명시적으로 의존한다.
  • 실제로 MyServiceImpl객체를 사용하지 않더라도 의존성 해결이 안되면 컴파일이 안 된다.
  • 테스트시 테스트 전용객체(Mock Object)를 할당해야 한다.
  • 생성과 사용 로직이 섞여있어서 모든 실행 경로도 테스트 해야 한다.
  • 책임이 여러개라는 말은 SRP(단일 책임 원칙)을 깬다.
  • MyServiceImpl이 모든 상황에 적합한 객체인지 알 수 없다.

결국, 위와같은 기법은 가볍게 한 번정도 사용할때는 상관없지만 사용빈도가 높아질수록 문제가 많아진다.

그렇기에 시스템의 생성과 사용 로직을 분리해야 한다.

Main 분리

• 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성 되었고 의존성이 연결되었다고 가정하는 방법.

• 그림11.1의 화살표 방향을 보면 모든 화살표가 main에서 애플리케이션을 가리킨다. 즉, 애플리케이션은 main이나 객체가 생성되는 과정을 모르고 생성 되었을 거라고 가정한다.