IoC 는 Spring 만의 기술이 아니다. 또한 아주 폭넒은 표현이다.
Inversion of Control , 제어의 역전 이라는 뜻을 지녔는데, 객체나 시스템의 실행 흐름을 개발자가 컨트롤 하는 것이 아닌, 외부에서 컨트롤 하는 형태를 말한다.
(초딩때 나랑 형이 받은 세뱃돈의 제어권을 엄마가 갖고있던것도 IoC겠다.)
왜 IoC 가 필요했을까?
그냥 생각해봐도, 엔터프라이즈 차원에서 객체가 너무 많다. 같은 객체가 여러곳에서 쓰이고, 이를 컨트롤하는 개발자도 많다. 근데 모든 개발자에게 컨트롤 하는 권한이 있는 상태는 캡슐화 위반이다. (시스템 요구사항에 따르면 삭제하면 안되는 객체를 삭제할 수 도 있는 상태이다.)
이제는 개발자들이 아닌 시스템의 한곳에서 제어한다.
Spring은 이러한 모든 권한을 ApplicationContext로 모았다. 이곳에서 객체의 생명주기도 관리하고, 의존관계도 관리하고, 그밖에 다양한 작업들을 수행하는 구조가 형성되어있다. 아주 규율적이다.
[방법1]
public class A {
private B b;
public A()
b = new B();
}기존에 개발자가 이런식으로 A와 B의 의존관계를 말하고 직접 생성했다면,
[방법2]
public class A {
@Autowired
private B b;
}이제는 이렇게 컨테이너를 통해서 객체를 주입받는 것이다.
정리하면..
객체 간의 의존성을 코드 내에 구현하면, 클래스의 변경이 발생할 때 해당 클래스를 참조하는 클래스의 코드 또한 모두 변경해야 한다. 이는 유지보수성을 떨어뜨리는 일이다. 또한 객체 관리 권한이 많아지는데에 있어서 캡슐화 위반의 문제도 존재한다. 분명 이밖에도 다양한 문제들이 있을것이다.
IoC(Inversion of Control)은 객체 간의 의존 관계를 컴파일 시간이 아닌 런타임에 설정함으로서 객체 간 결합도를 떨어뜨려 유지보수성을 증가시키는 방식이다. 스프링에서는 IoC 컨테이너가 이러한 구조를 만들어준다.
자 이제 조금은 기술적으로 들어가서 IoC의 방식을 살펴보자. 다음글
