왜 조립까지 신경 써야 할까?#
- 아키텍처에 대해 중립적이고 인스턴스 생성을 위해 모든 클래스에대한 의존성을 가지는 설정 컴포넌트(configuration component)가 있어야 한다.
- 이유: 코드 의존성이 올바른 방향을 가리키게 하기 위해
- 부수효과: 클래스가 필요로 하는 모든 객체를 생성자로 전달 수 있다면 실제 객체 대신 목으로 전달할 수 있고, 이렇게 되면 격리된 단위 테스트를 생성하기 쉬워진다.
- 설정 컴포넌트의 역할:
- 우리가 제공한 조각들로 애플리케이션을 조립
- 설정 파일이나 커맨드라인 파라미터 등과 같은 설정 파라미터의 소스에도 접근할 수 있어야 한다.
- 설정 컴포넌트는 단일 책임 원칙을 위반하는게 맞지만, 애플리케이션의 나머지 부분을 깔끔하게 유지하고 싶다면 이처럼 구성요소들을 연결하는 바깥쪽 컴포넌트가 필요하다.
평범한 코드로 조립하기#
- 단점:
- 모든 클래스를 인스턴스로 생성한 후 연결하는 것을 직접 코드로 작성하는 것은 비효율적이다.
- 각 클래스가 속한 패키지 외부에서 인스턴스를 생성하기 때문에 이 클래스들은 전부 public이어야 한다.
- 이렇게 되면 유스케이스가 영속성 어댑터에 직접 접근하는 것을 막지 못한다.
- package-private 접근 제한자를 이용해서 이러한 원치 않은 의존성을 피할 수 있었다면 더 좋았을 것이다.
- 다행히도 package-private 의존성을 유지하면서 이처럼 지저분한 작업을 대신해줄 수 있는 의존성 주입 프레임워크들이 있다.
스프링의 클래스패스 스캐닝으로 조립하기#
- 스프링은 애플리케이션 컨텍스트를 조립하기 위한 몇 가지 방법을 제공하는데, 가장 인기 있는 방법인 클래스패스 스캐닝을 살펴보자.
- 스프링은 클래스패스 스캐닝으로 클래스패스에서 접근 가능한 모든 클래스를 확인해서
@Component 애너테이션을 붙은 클래스를 찾는다. - 장점: 애너테이션 덕분에 코드를 읽는 사람들은 아키텍처를 더 쉽게 파악할 수 있다.
- 단점:
- 클래스에 프레임워크에 특화된 애너테이션을 붙여야 한다는 점에서 침투적이다.
- 스프링 전문가가 아니라면 원인을 찾는 데 수일이 걸릴 수 있는 숨겨진 부수 효과를 야기할 수도 있다.
- 해로운 마법: 애플리케이션 컨텍스트에 실제로 올라가지 않았으면 하는 클래스가 있을 수 있어도, 애플리케이션 컨텍스트를 악의적으로 조작해서 추적하기 어려운 에러를 일으킬 수도 있을 것이다.
스프링의 자바 컨피그로 조립하기#
- 애플리케이션 컨텍스트에 추가할 빈을 생성하는 설정 클래스를 만든다.
@Configuration 애노테이션틀 통해 이 클래스가 스프링의 클래스패스 스캐닝에서 발견해야 할 설정 클래스임을 표시해둔다.- 빈 자체는 설정 클래스 내의
@Bean 애너테이션이 붙은 팩터리 메서드를 통해 생성된다.
- 장점:
- 여전히 클래스패스 스캐닝을 사용하고 있기는 하지만, 모든 빈을 가져오는 대신 설정 클래스만 선택하기 때문에 해로운 마법이 일어날 확률이 줄어든다.
- 영속성 계층, 웹 어댑터, 애플리케이션 계층의 특정 모듈을 위한 설정 클래스를 따로만들 수 있다.
@Component 애너테이션을 코드 여기저기에 붙이도록 강제하지 않는다.
- 단점:
- 설정 클래스가 생성하는 빈이 설정 클래스와 같은 패키지에 존재하지 않는다면 이 빈들은 public으로 만들어야 한다.
- 가시성을 제한하기 위해 패키지를 모듈 경계로 사용하고 각 패키지 안에 전용 클래스를 만들 수는 있다. 하지만 이렇게 하면 10장에서 이야기할 테지만 하위 패키지를 사용할 수 없다.