[bootCamp][항해99] 항해 4주차 마무리 - Ioc , DI, Bean?

항해를 시작한지도 벌써 한 달이 다 되어간다.

부트캠프를 하면 당연하게도 모든 생활이 다 코드 중심으로 돌아간다.

 

새해 첫 꿈을 꾸었는데,

코드를 짜는 꿈을 꾸었다.

 

일어나서도 놀라지 않았다.

노트북을 열고 다시 할 일을 했다.

 

회고가 점점 올드보이 감금일기처럼 되어간다.

낄낄~

 

/////////////////////////////////////////////////////////////////////////////////////

 

이번에 스프링을 공부하면서 Ioc, DI, bean에 대해서 정리한 적이 있다.

 

https://kirinman.tistory.com/54

IoC (Spring에 국한된 것 아님!)

 

 

https://kirinman.tistory.com/55

DI

https://kirinman.tistory.com/57

스프링 컨테이너 / @Bean /@Configuration

 

세부 내용은 각각 게시글로 작성한 적이 있으니, 이번에는 한 번 정리한다 생각하고 다시 적어보고자 한다!

 

먼저 제어의 역전이라고 불리는 Ioc. 

프로그램의 제어 흐름을 개발자가 직접 제어하는 것이 아니라 외부에서 관리하는 것을 말한다.

 

이전 게시글에서는 상황에 빗대어 설명하였는데, 

내가 이해하기 쉽게 쓰자면, 내가 뭔가를 호출하는 것이 아니라 프레임워크 같은 것이 대신 호출해 주는 것으로 보면 된다.

 

DI는 의존성 주입 또는 의존관계 주입이라고도 불리며,

객체의 의존관계를 개발자가 아니라 외부에서 주입하는 것을 말한다.

 

이를 통해서

클라이언트 코드를 변경하지 않고도 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있으며,

정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

(DI 이점은 수정하기를 좋아하는 기획자를 위한 대비책!! 마감 직전까지 할인 정책을 고정금액으로 할지 %로 할지 고민하다가 끝판에 바꾸는 기획자. 그럴때 DI를 통해 코드를 다 뜯어고치지 않고도 구현체만 갈아끼우는 것을 상상하자)

 

다만 나는 의존성보다는 의존관계라고 말하는 것을 조금 더 선호하는데, 이건 순전히 나의 이해력 문제일지도 모르겠다.

나는 의존성, 의존하는 성질이라는 한자어가 실제 사용되는 용도와 어긋나 보였다.

 

DI에서 말하는 Dependency는 단일 객체를 다루는 것이 아니라 여러 객체간의 관계 속에서 형성이 되는 것인데,

이걸 의존성이라고 표현하면 조금 헷갈리지 않나 싶다.

(그냥 내가 이해를 못하는 것 같기도 함. 반박시 다른사람들 말이 다 맞음.)

 

bean을 설명하기 이전에는 먼저 스프링 컨테이너를 한 번 설명해야 할 것이다.

먼저 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 DI 컨테이너라고 하는데, 스프링에서는 이러한 역할을 하는 것을 스프링 컨테이너라고 한다.

(더 정확히는 BeanFactory, ApplicationContext로 구분해서 이야기하는데, BeanFactory를 사용하는 경우는 거의 없어 일반적으로 ApplicationContext를 스프링 컨테이너라고 한다.)

 

여기에서 bean이 등장하는데, 스프링 컨테이너에 등록된 객체를 말한다. 

추가로 컴포넌트 스캔이나 @Configuration이라던지를 더 설명해야 할 것 같지만, 이 부분은 조금 더 찾아봐야 정확하게 쓸 수 있을 것 같다.