IOC : 객체가 자신이 사용할 객체를 스스로 선택하지 않고 스스로 생성하지 않는다
Order의 생성자를 통해 주입하게 된다
Order객체가 스스로 생성하지 않고 Voucher에 대해서 주입을 받게댐
- OrderContext는 개별 레퍼지토리 클래스에대해 생성책임
OrderService가 어떤 VoucherService와 orderService를 가지는지 관계에 대한 책임
- OrderService는 VoucherService와 OrderRepository에 의존관계(생성자를 통해 주입 받고 있음)
OrderService는 Voucher을 이용해 Order을 만든다.- voucherId가 없는경우를 고려해 있을때와 없을때 두가지 경우로 Order을 만든다.
- VoucherRepository와 의존관계를 가짐
- voucherId를 이용해 VoucherRepository에서 Voucher을 찾아 반환해줌
Voucher가 없는경우에는 에러 발생하도록 Throw
- Repository는 실제 구현할때 다른 데이터베이스로 변동될 가능성이 있기 때문에 주로 interface로 생성
- Voucher은 없을수도 있기 때문에 Optional로 생성
- Voucher에 대한 null처리
- voucher가 없을때 : empty
voucher가 있을때: optional.of를 통해 voucher 전달- totalAmout: vocher가 있을땐 할인된 금액 , 없을땐 그대로 반환
- OrderTest가 OrderContex를 통해 Order가 만들어지고 해당서비스를 가지고오도록 변경
ApplicationContext :ioc Container
개별 객체들의 의존관계설정이 자동으로 이루어지고 객체들의 생성과 파괴 조합등을 함
ioc컨테이너에게 클래스를 사용할거라는 registrer 생명주기를 관리하면서 인스턴스 생성
이러한 iocContainer을 스프링에서는 ApplicationContext라는 인터페이스를 통해 제공 (빈 팩토리 상속 )
빈은 ioccontainer에 의해 관리되어지는 객체를 말함
ApplicationContext는 실제로 만들어야 할 정보를 Configuration Metadata로부터 받아온다. 이 메타데이터를 통해 빈을 등록
OrderContext -> Appconfiguration
- OrderContext -> Appconfiguration 클래스 이름 변경
@Bean을 통해 빈으로 등록(@Configuration)
아래처럼 코드를 변경해도 스프링이 빈에 등록되어있는 객체를 알아서 찾아서 넣어줌
- applicationContext를 생성해 AppConfiguration을 등록해준다.
applicationContext를 통해 빈객체를 얻어올수 있다.
이때 타입으로 가져오는 방식과 이름으로 가지고 오는방법 두가지가 있다. (여기서는 이름으로 OrderService객체를 가져옴)
defendency Injection :Ioc를 구현하는 패턴중 하나
지금까지 우리가 했던건 생성자 주입 패턴