IoC/DI를 하는 이유

IoC/DI(Inversion of Control / Depedency Injection)을 하는 이유는 의존성을 피하기 위함이다. 프로그램의 소스코드가 얽히고 설키면서 의존성을 가지는 여러가지 상황이 있는데 IoC/DI에서 해결을 하고자 하는 것은 클래스내에 생성을 하여 추후 생성해야되는 클래스가 바뀌는 경우 변경된 클래스의 생성으로 모든 소스코드를 바꿔야 하는 부분을 해결하기 위하는 방법이다. 

스프링과 같은 프레임워크가 없을 때는 이런 문제를 해결하기 위해서 디자인패턴에서 팩토리클래스라고 부르는 팩토리 계열의 클래스를 만들어두고 객체의 생성은 팩토리에게 위임을 하고 실제 생성되는 클래스를 받아서 써야되는 부분에서 팩토리 클래스에 객체생성을 요청함으로서 추후에 생성되는 클래스가 변경이 되더라도 팩토리 클래스만 변경을 하면 연쇄적인 변경을 하지 않도록 하는 방법을 이용하였다.

하지만 스프링이 그런 팩토리라는 역활을 해줌으로서 개발자들이 객체생성을 전담하기 위한 팩토리 클래스를 만들지 않아도 되도록 해주는 것이다. 이를 컨테이너라고 부르며 스프링프레임워크를 IoC/DI 컨테이너라고 부르는 것이다.

Job이라는 인터페이스를 두고 직접생성, Factory를 이용하는 방법 스프링을 이용하는 방법 이렇게 코딩을 해보았다. 지금 Engineer라는 클래스나 Doctor라는 클래스를 생성하여 Job 인터페이스를 리턴해주고 있다. 만약 Engineer 클래스가 변경되어 다른 클래스명으로 변경이 될 경우를 가정할 때 다음과 같은 상황이 만들어진다.

1. 직접 생성 : 소스코드 곳곳을 따라다니며 new Engineer() 이 코드를 변경해주어야 한다.

2. Factory 이용 생성 : Factory 클래스내에서 생성하는 부분만 변경하면된다.

3. 스프링 이용 생성 : getBean 부부만 변경하면된다. 하지만 스프링을 이용하는 우리는 저렇게 수동적으로 getBean을 사용하지 않는다.생성가능한 bean 클래스 상단에 @Component 라는 어노테이션을 주고 사용하고자 하는 클래스 내에서 @Autowired 어노테이션으로 Engineer 클래스를 지정하면 클래스가 주입되어 사용할 수 있다. 이럴 경우는 Factory 클래스도 필요가 없게 된다.