4장: 추상화

4장의 내용을 요약한다.

contract를 위해서 interface를 사용한다.

객체는 '어떻게 해야 하는가?'가 아닌 '무엇을 해야 하는가?'만을 정한다. 이때 객체들끼리는 Contract를 맺고 주어진 책임을 수행해야 한다. 이런 흐름이 전체 프로그램이 일관성과 확장성을 갖도록 한다. Contract를 정의하기 위해서 interface라는 추상화를 사용한다. 문법 설명 생략.

Autowired의 역할은 컨텍스트에 등록된 Bean을 찾아서 DI를 하는 것이다.

이때 클래스의 생성자가 하나라면 굳이 @Autowired를 명시하지 않아도 된다. 두 개 이상일때는 지정해줘야 한다. 추가로 만약 해당 Bean이 컨텍스트에 존재하지 않는다면 스프링은 에러를 발생시킨다.

@ComponentScan은 패키지명이나 클래스명을 지정할 수 있다.

패키지명을 지정하는 방식은 한번에 많은 클래스를 포함시킬수 있지만 패키지명이 변경되었을때 디버깅이 어려울 수 있다. 반면 클래스명 지정은 작성내용이 많아질 수 있겠지만 클래스명이 변경되었을 때 컴파일 되지 않으므로 디버깅에 용이하다.

Context에 Bean을 요청할 때 추상화에서는 어떻게 작동할까?

이역시 @Primary와 @Qualifier를 이용한다. Primary로 디폴트 implementation을 지정해놓고, 특정 상황에서는 Qualifier를 이용해서 원하는 구현체를 가져오는 방식이다.

나중에 원하는 구현체를 Qualifier로 선택하면 된다.

클래스의 책임에 따라서 stereotype annotation를 마킹하기도 한다. 예를 들어서 @Service나 @Repository가 있다.