제어의 역전(IoC, Inversion of Control)

기존에는 클라이언트 구현 객체에 필요한 서버 구현 객체를 생성하고 실행하였습니다.

예제 #1 

public class ServiceA {   private Car car;   public ServiceA() {     this.car = new Car();   } }

위와 같은 경우 ServiceA 라는 Class 에서 b 라는 Car 객체를 직접 생성하고 실행하고 있습니다.

 

예제 #2

public class ServiceA {   private Car car;   public ServiceA(Car car) {     this.car = car;   } }

이렇게 바꾸게 되면 Car b 객체는 외부에서 생성되어 할당하게 됩니다. 즉 직접 Class 내에서 생성하지 않고 외부에서 제어하게 되는 것을 제어의 역전이라고 합니다.

 

특별히 큰 차이는 없어보이지만 Car 라는 Class 가 추가상화되어 Hyundai, Kia 등으로 구현이 되었다면 첫번째 코드(예제 #1)는 아래와 같이 표현할 수 있습니다.

public class ServiceA {   private Car car;   public ServiceA() {     this.car = new Hyundai();   } }

이 경우 Hyundai 가 아닌 Kia 로 생성하고 싶을때는 클라이언트 구현 객체를 직접 변경하는 수밖에 없습니다.

이는 역할(Car)과 구현(Hyundai)을 분리했다고는 할 수 있지만 추상(Car) 뿐만 아니라 구현(Hyundai) Class 에도 의존(DIP*)하고 있으며, Kia 로 변경하기 위해서는 클라이언트 코드를 수정해야 하기때문에 OCP* 도 위반하게 됩니다.

1) DIP (의존 관계 역전 원칙, Dependency inversino pricinple) : 추상화에 의존해야지 구체화에 의존하면 안된다!!
2) OCP (개방/폐쇠 원칙, Opne/Closed principle) : 확장에는 열려 있어야 하나 변경에는 닫혀있어야 한다

따라서, 이 문제를 해결하기 위해서는 "예제 #2" 처럼 외부에서 Car Class 를 구현한 객체를 넘겨주는 것이 객체지향적으로 좀더 잘 설계되었다라고 할 수 있습니다. 

 

공연으로 예를 들자면 ServiceA 라는 배우는 본인의 역할(연기)에만 집중하고 다른 배우(Car)를 섭외(Car Class 생성 및 할당)하는 것에는 신경쓰지 않는 것과 같다고 할 수 있습니다.