IOC에 대해 알아보자.
IOC란 International Olympic Committee의 약자로 국제 올림픽 위원회를 말한다.
IoC란 제어의 역전 IoC(Inversion of Control)이다.
제어의 역전이란 말 그대로 제어권이 역전되었다는 것을 말하는데,
개발자가 가지고 있던 제어권을 IoC 컨테이너에게 넘김으로써 개발자는 비즈니스 로직에 집중할 수 있도록 해주는 개념이다. 제어권을 넘겨 받은 Ioc 컨테이너는 객체의 생성, 생명주기, 의존성 관리 등을 담당하고, 개발자가 객체를 직접 생성하는 대신 DI를 통해 필요한 객체를 제공 받는다. 이렇게 IoC 컨테이너가 객체 생성과 관리를 담당하게 되면서 모듈간의 의존성 및 결합도가 낮아지고 유지보수성과 확장성을 높일 수 있다는 장점이 있다. 또한 개발자는 필요한 객체를 직접 생성하거나 관리하지 않아도 되므로 코드의 재사용성과 TDD(테스트 주도 개발) 용이성도 향상된다.
DI에 대해 알아보자.
해병대 훈련소의 교관을 DI라고 하는데, 어떤 약자라고 들었는데 까먹어버렸다...
개발에서 DI란 Dependency Injection의 약자로 의존관계 주입이라고 한다. 위에서 IoC컨테이너에서 객체의 생성, 생명주기, 의존성 관리 등을 담당한다고 했다. 제어권을 IoC컨테이너가 가지고 있기 때문에 개발자가 필요로 하는 객체를 직접 생성하는 것이 아니라 IoC컨테이너가 객체를 개발자에 전달해주는데 이 모습이 마치 주입 해주는 것 같은 느낌이라서 Injection이라는 말을 사용하는 것 같다. 예를 들어, ~ServiceImpl에서 Repository를 거쳐 DB에 도달해 데이터를 가져와야할 경우
public class ~ServiceImpl implements ~Service{
private MemberRepository memberRepository= new ~MemberRepository();
}
🍄 이런 모습을 많이 보았을 것이다. 하지만 이 모습은 현재 MemberRepository라는 인터페이스를 의존 하고 있지만, 또 ~MemberRepository()라는 구현 객체를 의존 하고 있는 모습이다. 이렇게 되면 우리가 항상 입이 닳도록 말하는 SOLID원칙을 지키지 않는 모습으로 볼 수 있다. "추상화에 의존해야지 구현 객체에는 의존하면 안된다"라는 DIP를 지키지 않고 있고, 또한 수정시에 코드 변경이 일어날 수 밖에 없는 구조이므로, "확장에는 열려있어야 하고, 수정에는 닫혀 있어야 한다"라는 OCP를 위반한 모습으로 볼 수 있다. 그렇기 때문에 DIP와 OCP를 지킬 수 있도록 추상화에만 의존하도록 바꿔줘야한다.
public class ~ServiceImpl implements ~Service{
private MemberRepository memberRepository;
}
이렇게 말이다. 하지만 이렇게 실행하면 NPE(Null Pointer Exception)가 발생한다. 그러면 어떻게 바꿔줘야 할까..?
