스프링 프레임워크 이야기 - IoC
지난 번 초기에 프레임워크에 대해 설명하면서 마지막에 스프링 프레임워크 구조를 명시했었다.
2015/08/14 - [Spring/Spring 이야기] - 프레임워크에 대한 이야기
그저 전반적인 프레임워크와 스프링 프레임워크에 대해 간략하게 했었다.
그럼 이제 스프링 프레임워크로 진입해야 한다.
스프링 프레임워크에 대해 알아가는 과정 중에 있는 것은 IoC라는 녀석이다.
앞선 글에서도 살짝 언급 했던 컨테이너와 함께 IoC를 이야기 했었다.
그렇다면, 이제 이야기를 해볼까 한다.
IoC 는 무엇일까 ?
IoT는 아니다.
Inversion of Control의 약자이며, 한국어 번역본으로는 제어의 역전이라고 되어있다.
보통 쉽게 말해서 프로그램의 제어 흐름 구조가 뒤바뀌는 것을 말하며,
오브젝트가 자신이 사용 할 오브젝트를 스스로 선택하지 않는다.
고로 자신 조차도 어떤 시점에서 생성되는지? 어디에 쓰이는지를 알 수 없다.
당최 무슨소리...?하겠지만,
쉽게 말하면 "내가 작성한 코드가 내 마음대로 동작하는 것이 아니라 어떤 녀석에게
나의 권한을 위임해 주는데 그 위임한 권한을 가진 녀석이 컨테이너이다."
그 컨테이너에서 오브젝트에 대한 권한을 가진다.
그러므로 생성 및 관계에 대한 정보를 컨테이너가 관리하며, 주인장 행세를 한다는 뜻이다.
사실 지분은 내가 소유 했으나(코드 작성), 위임장을 주어(IoC) 마치 내 의지인양 행동케 한다는 뜻으로
비유 아닌 비유를 들 수 있다.
위의 이미지처럼 클래스 호출 방식의 종류를 볼 수 있도록 준비를 해보았다.(구글에 널렸다)
주로 사용하는 방식이 직접 사용,생성,호출하는 첫 번째 그림과 같은 모습일 것이다.
그런데 문제점은 변경 사항을 적용하려고 하면 코드 전체를 수정 해야 한다.
이것은 응집도가 낮다고 표현한다.
그 두번째 모습이 나오기 전에는 본래 상속을 통한 호출 방식을 사용했으나,
그러한 상속 구조는 다중 상속을 허용하지 않는 자바에서는 변경 사항에 대해
충분한 처리가 불가능해진다는 한계가 존재했다.
심지어 상속구조는 클래스 간 강한 결합도를 만들어 주므로 좋은 모습이 아니다.
그래서 나온 것인 인터페이스를 이용 한 것이다.
그럼에도 불구하고 인터페이스를 이용 하더라도 호출 클래스의 수정이 요구 된다는 한계가 존재한다.
세번째 그림과 같은 팩토리를 이용하는 방법이다.
이 개념부터는 디자인 패턴이라는 프로그래밍 설계 개념이 들어 간다.
일단, 팩토리를 이용하더라도 '의존'적인 클래스를 보기 마련이다.
어떻게 하든 팩토리를 의존함으로 오브젝트를 생성 하기 때문이다.
디자인 패턴이란 ?
헉헉. 많이 올라 왔다. 우리는 많이 올라 왔어...(스프링 입문자는 웁니다)
자 이번에는 마지막 그림인 IoC 호출 방식
즉, 컴파일 시점에는 어떠한 '관계'가 없다.
그러나 실행 시점에는 '관계'를 조립기라는 외부의 녀석이 만들어 준다는 점이 다르다.
그럼으로 훨씬 응집도는 높고, 결합도는 낮은 관계를 형성 할 수 있다는 점이다.
그래서 IoC를 사용하는 이유이자 강점이 된다.
스프링에서는 제어권을 가지고 직접 만들고, 관계를 부여하는 오브젝트를 Bean이라고 부른다.
자바빈, EJB에서 말하는 빈과 비슷한 오브젝트 단위의 어플리케이션 컴포넌트를 말한다.(참조:토비의 스프링)
스프링에서는 빈의 생성과 관계설정를 Bean Factory라는 녀석이 해준다.
이 녀석이 바로 스프링에서의 IoC를 담당하는 녀석이다.
그리고 Acpplication Context라는 녀석이 그 뒤에 있는데 이 녀석은
Bean Factory보다 더 기능이 많다.
(엔터프라이즈 개발에 필요한 기능을 포함한 Bean Factory라고 생각하면 된다.)
일단 여기까지 IoC의 개념을 맛보았다.
물론 이해는 코드로 설명하는 것이 빠르겠으나,
오히려 더 독이 될지도 모른다는 생각에 말로 풀어 설명을 해보았다.
* 틀린 점은 지적 환영합니다.