스프링에서 많이 쓰이는 단어인 IOC와 DI에 대해 알아봅시다.
잘못 설명했거나 피드백 있으면 언제든지 댓글 작성해주세요!!
오브젝트 생성, 관계설정, 사용, 제거 등 오브젝트 전반에 걸친 모든 제어권을 애플리케이션이 갖는게 아니라 프레임워크의 컨테이너에게 넘기는 개념
스프링에서는 위에 설명한 오브젝트를 빈(Bean)이라고 부릅니다.
IOC는 디자인 패턴중 하나이며 번역한다면 '제어의 역전'이라고 합니다.
개발자가 객체의 생성, 소멸 등 제어를 하는 것을 어떤 프레임워크나 컨테이너가 대신 수행하는 의미라고 생각하면 편합니다.
개발자가 어떤 객체의 의존관계의 제어를 한다. == 기존 객체 지향 설계 방식
개발자가 아닌 다른(프레임워크, 컨테이너)가 의존관계를 대신 제어해 준다. == 제어의 역전
Cpu.java
public class Cpu {
.
.
.
}
Computer.java
public class Computer {
private Cpu cpu;
.
.
.
public Computer() {
this.cpu = new Cpu();
.
.
.
}
}
많이 쓰이는 객체 지향적인 설계입니다.
Computer.java를 보시면 Computer
생성자에서 Cpu
클래스의 의존 관계를 제가 코드를 쳐서 의존관계를 제어해 줬습니다.
여기서 스프링에서 제공하는 @Autowired
어노테이션을 사용하여 Computer
클래스를 구성해보겠습니다.
public class Computer {
@Autowired
private Cpu cpu;
.
.
.
}
@Autowired
어노테이션을 사용해서 제가 의존관계를 설정해주는 코드가 사라지고 스프링 프레임워크에 의존관계 제어권을 맡길 수 있게 되었습니다.
또 코드를 간결하게 해주고 객체간의 결합도를 낮출 수 있습니다.
클래스 간의 의존성을 클래스 외부에서 주입하는 것을 뜻한다.
따라서 DI는 IOC의 종류중 하나다.
위 예시에서 설명했듯 @Autowired
어노테이션을 사용하면 스프링 컨테이너에 존재하는 Cpu 빈
을 Computer
클래스에 주입을 했습니다.
그렇다면 의존성 주입을 왜하는 것일까요?
DI를 사용하지 않고 Cpu
클래스를 상속을 받은 Intel
과 Amd
클래스를 사용해야 한다면 다음과 같은 코드를 볼 수 있습니다.
class Cpu {...}
class Intel extends Cpu {...}
class Amd extends Cpu {...}
public class Computer {
private Cpu cpu;
public Computer() {
this.cpu = new Intel();
// or
this.cpu = new Amd();
}
}
만약 Computer
클래스가 100개가 있고 Cpu
클래스를 Intel
에서 Amd
로 바꿔야 한다면 상당한 노력과 시간이 걸릴 것입니다.
의존성 주입(DI)를 사용해서 다음과 같은 코드를 만들 수 있습니다.
public class Computer {
private Cpu cpu;
@Autowired
public Computer(Cpu cpu) {
this.cpu = cpu;
}
}
의존성 주입을 이용해서 객체간의 결합도를 느슨하게 했습니다.
이를 통해서 시간도 절약하고 유지보수도 편하게 할 수 있습니다.