일반적인 제어의 흐름

<aside> 💡 객체 생명주기를 직접 제어한다.

</aside>

• main() → 다음에 사용할 오브젝트 결정 → 결정한 오브젝트 생성
• 만들어진 오브젝트에 있는 메소드 호출 → 그 오브젝트 메소드 안에서 다음에 사용할 것을 결정하고 호출하는 식의 작업 반복

public class A {
		private B b;
	
		public A() {
				this.b = new B(); //변경에 자유롭지 못하다.
		}
}

제어의 역전

<aside> 💡 객체 생명주기를 위임한다.

</aside>

• 제어권을 상위 템플릿 메소드에 넘기고, 자신은 필요할 때 호출되어 사용함. (언제 호출될지는 모름)

public class A {
		private B b;

		//자신이 직접 객체를 생성을 안하고, 주입받아서 사용한다. (제어의 역전)
		public A(B b) {
			this.b = b; //변경이 자유롭다.
		}
}

public class UserDao {
		Connection connection;		

		public UserDao(Connection connection) {
				this.connection = connection; //coonnection 의 생명주기를 IoC 하고있다.
		}
}

//가장 간단하게 만들어본 IoC 컨테이너 / IoC 프레임워크
public class DataFactory {
		public UserDao userDao() {
				return new UserDao(connectionMaker()); //UserDao에 connection을 주입해준다.
		}

		public AccountDao accountDao() {
				return new AcoountDao(connectionMaker());
		}

		public MessageDao messageDao() {
				return new MessageDao(connectionMaker());
		}
		
		public Connection connectionMaker() {
				return new Connection();
		}

IoC를 사용하면, 역할과 관심을 분리해 응집도를 높이고, 결합도를 낮출 수 있다.

이에 따라 변경에 유연한 코드를 작성할수 있는 구조가 된다.

→ 즉 IoC는 기본적으로 프레임워크만의 기술도 아니고 프레임워크가 꼭 필요한 개념도 아니다. 단순하게 생각하면 디자인 패턴에서도 발견할 수 있는 것처럼 상당히 폭 넓ㅅ게 사용되는 프로그래밍 모델이다.