👨‍🔧유안의 Spring IoC/DI

[10분 테코톡] 👨‍🔧유안의 Spring IoC/DI 를 읽고 정리

스프링의 대 삼각형

• IoC/DI: Inversion of Control / Dependency Injection
• AOP: Aspect Oriented Programming
• PSA : Portable Service Abstraction

IoC/ DI란

• 스프링 프레임워크의 근간
• 오브젝트의 생명주기와 의존관계에 대한 프로그래밍 모델
• 유연하고 확장성이 뛰어난 코드를 만들 수 있게 해주는 프로그래밍 모델

유연하고 확장성이 뛰어나다

⇒ 변경이 있을 때 수정이 쉽다

⇒ 수저할 부분만 수정하면 된다

⇒ 관심사의 분리가 잘 이루어졌다.

전략패턴

관심사의 분리? 관련한 많은 디자인 패턴이 있다. 그중 대표적인 것이 바로 전략패턴

MovingStrategy라는 인터페이스를 만들고, 이에대한 구현체를 따로 구현하여 움직임에 대한 코드를 수정하고 싶을 때 자동차에 대한 수정을 하지 않고 MovingStrategy라는 인터페이스 혹은 구현체만 수정하면 된다.

하지만 다시 돌이켜 생각해보자

Car 객체는 스스로 어떤 MovingStrategy를 사용할지 선택할 수 없다. 자신이 사용할 MovingStrategy를 직접 생성하고 있지도 않다. 그러다 보니 자신이 어떤 MovingStrategy를 사용해서 작동을 하게 될지 조차 Car 객체 스스로도 모른다.

전략패턴의 사용이 곧 제어가 스스로에게 없음을 암시한다.

제어권은 Car 객체를 사용하는 객체인 Client에 존재한다.

Client관점에서의 전략패턴

Racing이라는 클라이언트 객체이다. 여기서 Car 객체에 대한 모든 제어를 하고 있음을 알 수 있다. Car 객체에 어떤 movingStrategy를 사용할 것인지 정해서 생성해주고 있으며 어떤 행동을 할 것인지(메소드의 사용)도 제어하고있다.

여기서 문제가 발생한다.

이 클라이언트 코드는 관심사의 분리가 적절히 이루어진 코드라고 보기 힘들다. Racing 이라는 객체의 책임은 Racing을 하는 것인지 자동차를 생성하는 것이 아니다. 즉 Racing 기능과 자동차 생성의 책임이 섞여있다고 볼 수 있다.

제어의 두 가지 관점

위 예시에서 알 수 있는 것은 제어에 두 가지 관점이 존재한다는 것이다. Car 생성에 대한 제어의 관점과 Car의 헹동에대한 제어의 관점 두가지이다.

제어의 두가지 관점을 제네릭하게 표현하자면 위 슬라이드와 같다. Racing 객체는 2번 관점에서의 제어가 어울리며 이에 대한 책임을 줘도 된다.

하지만 생성 관점에서의 제어는 분리되는 것이 좋겠다. → 팩토리 클래스의 필요성!

오브젝트 팩토리

이제야 관심사의 분리가 적절히 이루어졌다. 첫 번째로, 생성에 대한 제어권은 CarFactory가 담당하게 되었고,

두번째인 Car 객체 행동에 관한 제어는 Racing 객체가 담당하게 되었다

자동차의 움직임 방식을 변경하고싶다면?

→ Car factory의 생성자에 원하는 MovingStrategy의 구현체를 만들어 넣어주면 된다

Racing 방식을 바꾸고 싶다?

→ 레이싱 객체에서 자동차의 행동에 대한 코드를 수정하면 된다.

스프링 IOC/DI

---

스프링의 IOC/DI 기능과 위의 팩토리 클래스, 클라이언트는 굉장히 유사하다.

어떤 연관관계를 맺고 생성될 것인가?

• 팩토리클래스 → 스프링의 빈 컨테이너가 담당한다.

어떻게 사용될 것인가?

• 클라이언트 클래스→ 스프링 내부 코드가 담당한다.

우리는 스프링을 사용하면서, Controller, Service 그리고 각종 Bean들에 대해 구현체들을 구현하고 있지만 이것들이 어떻게 생성되고 어떻게 연관관계를 맺는지 전부 Config 파일, 그리고 빈 컨테이너가 담당해주고 있고 우리는 크게 관심을 갖지 않아도 된다.

++ 우리는 컨트롤러, 서비스 코드가 어떻게 호출되어서 언제 동작하는지에 관한 코드는 작성해본적이 없다.(클라이언트 클래스) 모두 스프링의 내부적인 클라이언트 코드가 담당해주고 있는 것이다.

결론

IOC/DI는 사실 우리가 사용하고 있는 코딩 패턴들이다.

관심사의 분리를 통해 유연하고 확장성이 쉬운 코드를 만들다 보니 자연스럽게 만들어진 프로그래밍 모델이다.