개발자 노트

[IOC 제어의 역전]

- 간단히 프로그램의 제어 흐름 구조가 뒤바뀌는 것이라고 설명할 수 있다.

 기존에는 모든 종류의 작업을 사용하는 쪽에서 제어하는 구조였다.

 main()[엔트리 포인트] -> 사용할 클레스 new(객체 생성) -> 생성한 객체의 메소드 호출 -> 호출된 메소드에서 다음에 사용 할 객체 등을 결정 및 객체 생성-> 생성한 객체의 메소드 호출

 이런 흐름의 개념을 거꾸로 뒤집는 것이 제어의 역전.

 객체가 자신이 사용할 오브젝트를 스스로 선택하지 않으며, 생성도 하지 않는다. (Factory에 위임)

 또한 객체 자신이 어떻게 만들어지고 어디서 사용되는지 알 수 없다. 모든 제어 권한을 다른 대상에게 위임하기 떄문이다.

 즉, 제어권을 상위 템블릿 메소드에 넘기고 자신은 필요할 때 호출되어 사용되도록 한다는 개념이다.

스프링에서

Bean

    : 스프링이 제어권을 가지고 집접 만들고 관계를 부여하는 오브젝트,

      스프링컨 컨테이너가 생성과 관계 설정, 사용 등을 재어해주고 제어의 역전이 적용된 오브젝트

    Bean Factory

    : Bean의 생성과 관계성정 같은 제어를 담당하는 IOC 오브젝트(스프링에서 좀더 확장한 애플리케이션 컨텍스트를 주로 사용)   

      오브젝트 펙토리에 대응되는 스프링의 애플리케이션 컨텍스트(= IOC 컨테이너, 스프링컨테이너, 빈 팩토리)

- Factory 패턴 사용

* 라이브러리 vs 프레임워크

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

- 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다. (프레임워크가 짜놓은 틀에서 수동적으로 동작해야 한다)

  보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다.

  분명한 제어의 역전 개념이 적용되어 있어야 한다.

[DI 의존관계 주입, Dependency Injection]

- 스프링 IoC 기능의 대표적인 동작원리

- 엄밀하게 말하면 오브젝트는 다은 오브젝트에 주입할 수 있는게 아니다. 오브젝트 레퍼런스가 전달될 뿐이다.

DI는 오브젝트 레퍼런스를 외부로부터 제공(주입)받고 이를 통해 여타 오브젝트와 다이내믹하게 의존관계가 만들어지는 것이 핵심이다.

- A가 B에 의존하고 있음을 나타낸다. B는 A에 의존하지 않는다. 즉, B는 A의 변화에 영향을 바지 않는다. (의존관계는 방향성이 있다.)

B가 변하면 그것이 A에 영향을 미친다는 뜻이다. B의 기능이 추가되거나 변경되어나, 형식이 바뀌거나 하면 그 영향이 A로 전달된다는 것이다.

- ConnectioMaker 인터페이스가 변하면 그 영향을 UserDao가 직접적으로 받게된다. 하지만 ConnectionMaker 인터페이스를 구현한 클래스인 DConnectionMaker등이 다른 것으로

바뀌거나 그 내부에서 사용하는  메소드에 변화가 생겨도 UserDao에 영향을 주지 않는다.

즉, 인터페이스에 대해서만 의존관계를 만들어두면 인터페이스 구현 클래스와의 관계를 느슨해지면서 변화에 영향을 덜 받는 낮은 결합도를 가지게되며 그만큼 변경에 자유로워진다.