숙련주차 WIL - DI, IoC, Bean

DI? Dependency Injection(의존성 주입)

(뭔소리여? 뭘 주입해?)

이 내용을 이해하려면 일단 의존성이 뭔지부터 짚고 가는게 좋다.

프로그래밍에서 의존성이란 - 얘가 바뀌면 쟤도 바꿔야 하는것.

-> 이건 '결합'과 관련이 있다. 우리가 가장 싫어하는 상황이 모다? 코드 하나 수정하면 얘가 관계되어 있는 모든 곳을 다 찾아서 다 수정해줘야 하는 극악의 작업상황.
이게 '의존성'이다. 이건 의존성이 강한 경우다.

일반적으로 강한 결합은 강한 의존성을 가진다. 너 없인 못살앙 (젠장 제발 독립좀 해라)

의존성은 너굴맨이 처리했으니 안심하라구 - 인터페이스를 쓰자

이런 골치아픈 상황을 해결하기 위해서 인터페이스를 쓴다.
인터페이스는 구현부가 비어있는 메서드 묶음이기 때문에, 내용물을 갖고있지 않다. 즉, 수정해줘야 할 부분이 없다는것.

• 그럼 내용물이 없다는거 아니야?
  -> 그 내용물은 자바가 알아서 넣어줄거임. 이걸 '의존성 주입'이라고 한다.
  의존성을 가질만한 애를 자바가 관리하게 해서, 의존도나 결합을 줄이는 것.
  -> 그래서 의존성 주입을 new의 주입이라고 표현하기도 한다. 필요한 객체를 클래스 외부에서 생성하여 필요한 곳에 주입하기 때문에, 생성자를 써서 끌어와야 해서.

인터페이스 하면 JPA 얘기가 빠질 수 없지 - JPA는 라이브러리나 프레임워크가 아님. 그냥 기술 명세.

참고 블로그는 여기

• JPA는 ORM을 사용하기 위한 인터페이스를 모아둔 것이기 때문!
  -> 그래서 Repository가 보통 Interface로 선언되는 것이다.
  -> 그래서 '이렇게 저렇게 쓰면 돼' 라는 지침은 있는데, 그렇게 쓰게 해주는 구현체(알맹이)가 없다.
  -> 그래서 ORM 프레임워크를 따로 써줘야 한다. 모드기(JPA)를 사면 코일이랑 액상(구현체)은 내가 알아서 해야 함. 들어있지 않음.
  -> 그래서 '우리는 이런 구현체가 있어요!' 하고 JPA ORM 프레임워크가 여러개 있는데, 개중 가장 유명하고 널리 쓰이는게 Hibernate.

• JPA니 구현체니 이거 왜 쓰는데?
  -> 이거 쓰면 내가 SQL 작업 직접 안해도 된다. 메소드만 호출하면 SQL 쿼리가 내부에서 알아서 만들어져서 돌아간다.
  -> 이거 안 쓰면 테이블 컬럼 변경됐을때 파라미터, 결과, SQL문 전부다 내가 수정해줘야 한다. 백엔드인지 데이터 엔지니어인지 알 수 없는 지경에 이를 수 있을 것.
  -> 이거 쓰면 어떤 관계형 DB를 쓰든 그 DB 속성에 맞춰서 쓸 수 있다. DB 바뀐다고 내가 고생 안해도 됨. JPA는 추상화된 접근 계층을 제공하기 때문.

IoC는 또 뭔데? 올림픽 위원회가 아니다

(이건 또 뭐야?)
그게 뭔데 - 내 심정을 아주 잘 대변해준 블로그

IoC의 기본 슬로건 - 'Don't call us. We'll call you.'

DI가 나오면 빠질 수 없는 IoC. 핵심은 '필요하면 부를테니 먼저 연락하지 마라.'
이 내용에 대해 보다보면 라이브러리와 프레임워크가 어떻게 다른지 나온다.

• 기존의 프로그래밍은 보통 다른 사람이 작성한 외부 코드(라이브러리)를 사용하는 경우, 구조를 코딩하는 사람이 만들게 되므로 코드의 생명주기도 만드는 사람에게 달려있다. 즉, 생명주기를 직접 관리하게 됨.

• 그러나 프레임워크를 쓰면 얘기가 다름. '이렇게 하면 저렇게 해줘' 라고 동작은 설정하지만, 그 외에 뭘 언제 갖다 쓰는지는 전부 프레임워크의 동작에 달려있다. 코드의 제어권이 사람 쪽에서 프레임워크 쪽으로 이동된것. 이게 제어의 역전.

• 그래서 스프링을 쓰면 제어의 흐름을 스프링이 컨트롤 하므로 제어권이 스프링 쪽으로 넘어간다.

Bean - 콩을 뿌려야 싹이 난다

IoC 컨테이너가 관리하는 자바 객체

• 좀더 쉽게는, Spring에 의해 생성되고 관리되는 자바 객체가 Bean.
  콩 아이콘 뜨면 Bean임. 참 쉽죠? (양심없음)

-> 단순히 new 연산자로 객체를 생성했을때는 그 객체는 Bean이 아니다.
-> ApplicationContext.getBean()으로 얻어질 수 있는 객체가 Bean이다.

(아니, 뭐라는거야?)

특정 어노테이션이 붙거나 빈 설정파일에 설정된 애들은 Bean이 된다!

• Controller, Service, Repository, 그리고 Component 붙은 애들은 Bean이 된다! -> 얘네는 Bean 자동등록이다! 이 어노테이션 붙으면 무조건 Bean으로 들어간다.

• Configuration과 Bean이 붙어있는 애들도 Bean이 된다! -> 얘네는 Bean 수동등록이다! '나 이거 Bean으로 쓸거야!' 인것.

• Spring boot 돌리는 클래스 보면 @SpringBootApplication 있는데, 이게 붙어있으면 이것의 하위 클래스에 있는 애들한테 Component 속성이 있는지 자동으로 찾아준다. 얘 속에 @Componentscan이 들어있기 때문.

• Component 속성이 있으면 왜요?
  -> Component는 Bean 자동등록 어노테이션임! 붙은 애들은 싹다 Bean으로 등록해주기 때문.
  자동등록 할 애들 있는지 알아서 스캔해주고 알아서 등록해준다는 얘기.