[토비의 스프링] 스프링의 IoC 공부 전 꼭 알아야 하는 팩토리

[세트] 토비의 스프링 3.1 (총2권) - YES24

---

  IoC랑 팩토리랑 무슨 상관이야?  

 

 흔히 스프링을 공부할 때 스프링의 세 가지 핵심 프로그래밍 모델(IoC/DI, AOP, PSA)을 스프링 삼각형이라고 부른다.이 중 우리가 먼저 살펴보게 될 프로그래밍 모델은 IoC다. 

 스프링이 제공하는 기술, API, 컨테이너도 이 방식으로 작성되어 있다. 가장 중요하고 핵심이 되는 기술이다. IoC를 이해하기 위해서는 먼저 팩토리에 대한 이해가 필요하다. 왜냐하면 IoC를 가능케하는 오브젝트가 팩토리로 구성되어 있기 때문이다. 이제 팩토리에 대해 알아보자!

 

세 가지 핵심 프로그래밍 모델에 대한 내용은 아래의 포스트를 참고하길 바란다.

[토비의 스프링] 나도 모르게 사용하고 있는 스프링의 기본 구성

---

  팩토리란  

객체 생성 방법을 결정하고 그렇게 만들어진 오브젝트를 돌려주는 오브젝트.
오브젝트를 생성하는 쪽과 생성된 오브젝트를 사용하는 쪽의 역할과 책임을 분리하는 목적으로 사용된다.

 

👉🏾 팩토리 적용 전 

public class A {
}

public class B {
    // 직접적으로 class A를 생성한다.
    A a = new A();
}

 

👉🏾 팩토리 적용 후

public class A {
}

// 팩토리 오브젝트
public class AFactory {
    public A getA() {
        return new A();
    }
}

public class B {
    // 간접적으로 class A를 생성한다.
    A a = new AFactory().getA();
}

 

  설계도 역할의 팩토리  

 

 오브젝트들의 관계를 분석해보자. A와 B는 애플리케이션에서 로직을 담당하게 될것이고, AFactory는 애플리케이션의 오브잭트들을 구성하고 관계를 정의하는 설계도와 같은 역할을 한다. 설계도라 하면 간단히 어떤 오브젝트가 어떤 오브젝트를 사용하는지 정의해놓은 코드라고 생각하면 된다.

 위와 같이 분리시 장점은 다양하지만 그중에서도 로직이 있는 오브젝트와 구조를 결정하는 오브젝트를 분리했다는 데 가장 의미가 있다. 

 

 

  제어권 이전을 통한 제어관계 역전  

 

👉🏾  일반적인 프로그램의 흐름 

 

 일반적으로 프로그램의 흐름은 min() 메소드처럼 Entry Point라고 하는 프로그램 시작 지점에서 "사용할 오브젝트를 결정, 생성, 오브젝트 속 메소드를 호출하고..... "가 반복된다. 이런 프로그램의 구조에서 각 오브젝트는 프로그램 흐름을 결정하거나 사용할 오브젝트를 구성하는 작업에 능동적으로 참여한다. 모든 종류의 작업을 사용하는 쪽에서 제어하는 구조다.

 

👉🏾 제어의 역전  

제어 흐름의 개념을 거꾸로 뒤집는 것

 

1. 자신이 사용할 오브젝트를 스스로 선택, 생성하지 않는다.

2. 자신도 어떻게 만들어지고 어디서 사용되는지 알 수 없다.

 

왜냐하면 모든 제어 권한을 자신이 아닌 다른 대상에게 위임하기 때문이다.

Entry Point를 제외하면 모든 오브젝트는 이렇게 위임받은 제어 권한을 갖는 특별한 오브젝트에 의해 결정되고 만들어진다.

 

👉🏾 제어의 역전으로 설명하는 라이브러리와 프레임워크의 차이

 

 흐름 제어의 권한으로 차이를 구분할 수 있다.

 

 라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다. 단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다.

 반면 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. 보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다. 분명한 제어의 역전 개념이 적용되어 있어야 한다. 애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 한다.

 

  프로그래밍 모델로서의 IoC  

 IoC는 프레임워크만의 기술도 아니고 프레임워크가 꼭 필요한 개념도 아니다. 단순히 생각하면 디자인 패턴에서도 발견할 수 있는 것처럼 상당히 폭넗게 사용되는 프로그래밍 모델이다. IoC를 적용함으로써 설계가 깔끔해지고 유연성이 증가하며 확장성이 좋아지기 때문에 필요하면 언제든 코드를 만들어 사용하면 된다.

 제어의 역전에서는 애플리케이션 컴포넌트의 생성과 관계설정, 사용, 생명주기 관리 등을 관장하는 존재가 필요하다. 그래서 애플리케이션 전반에 걸쳐 사용하려면 스프링과 같은 IoC 프레임워크의 도움을 받는 것이 유리하다.