발자국남기기

의도적으로 해당 타입의 스프링 빈이 다 필요한 경우도 있다. 예를 들어, 할인 서비스를 제공하는데 클라이언트가 할인의 종류를 선택할 수 있다면? 스프링을 사용하여 해결해보자. 위와 같이 테스트 코드를 작성하였다. 전에 만들어놓았던 AutoAppConfig를 통하여 컴포넌트 스캔을 진행하여 스프링 빈으로 등록한다.(@Component가 붙은 클래스 모두 등록) 그리고 우리가 static으로 만든 DiscountService또한 스프링 빈으로 등록시키는데 의존관계 주입시 List와 Map형태로 RateDiscountPolicy와 FixDiscountPolicy를 주입할 것이다. 테스트를 실행시켜보면 다음과 같이 Map와 List에 조회된 모든 빈들이 들어가있고, discountService 또한 정상적으로 ..

과거에는 수정자 주입과 필드 주입을 많이 사용했지만, 최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장한다. 불변 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.(불변) 수정자 주입을 사용하면, setXxx 메서드를 public으로 열어두어야 한다. 누군가 실수로 변경할 수도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아님 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계 가능 누락 프레임워크 없이 순수한 자바 코드를 단위 테스트 하는 경우에(수정자 주입을 사용) 아무런 오류가 발생하지 않지만 막상..