DI - 의존관계 주입

이번 포스팅에서는 스프링에서 중요한 DI의 개념에 대해서 적어보도록 하겠다.

 

DI - 의존관계 주입

DI(Dependency Injection)을 번역하면 의존관계 주입 혹은 의존성 주입으로 부른다.

허나, 의존이 하나의 관계를 띄고 있고, 그 관계가 상당히 중요한 역할을 하므로 의존관계라고 부르도록 하겠다.

 

먼저,의존관계 주입을 알기 위해서는 의존관계가 무엇인지 알아봐야 한다.

 

 

 

---

■ 의존관계란?

A는 B와 의존관계다. 라고 말한다면, 의존 대상 B가 변할 때, 그것이 A에 영향을 미친다.

예를 들어, 건축가가 있다고 치자. 그 건축가는 설계도를 보며 건물을 짓는다. 허나, 중간에 설계도가 변경이 되면 건축가는 다른 모양으로 건물을 짓게 될것이다. 설계도의 변화가 건축가에게 영향을 미쳤다. 이를 통해 건축가는 설계도에 의존한다고 말할 수 있다.

 

그리고, 이때 객체와 객체사이가 얼마나 의존하는지를 말하는것을 결합도(Coupling)이라고 한다. 좋은 소프트웨어 디자인은 Coupling을 낮게 하는 것이다. 즉, 소프트웨어 코드의 요소끼리 의존성이 높다면 그것은 안좋은 설계이다.

 

그냥 척보아도 그 위험성은 한눈에 알수 있다.

만약, A는 B에 의존하고 B는 C에, C는 D에 의존하고 있다고 가정해보자. 이때, D를 변경한다면, C,B,A가 꼬리에 꼬리를 물고 변경되어야 한다. 이처럼 높은 Coupling 즉,  과도한 의존성은 소프트웨어 에서 그다지 좋은 것처럼 보이지 않는다.

 

 

---

 

의존관계가 무엇인지 알았으니, 스프링에서 중요한 의존성 주입에 대해 살펴보자.

DI는 의존 관계를 외부에서 결정하여 주입해주는 것을 말한다. 스프링에서는 이러한 DI를 해주는 DI 컨테이너가 있다. 이 컨테이너가 객체들 간의 의존관계를 주입해준다.

 

만약, 의존관계의 생성을 객체 내부에서 직접 진행하면 무슨일이 벌어질까?

 

public class Constructer{
	
	private Blueprint blueprint;
	
	public Constructer() {
		this.blueprint = new Blueprint();
	}
	
}

아까 말했던 건축가 <-> 설계도의 관계이다.

위 코드에서 생성자를 보면 this.blueprint = new Blueprint(); 라는 코드를 사용함으로서 건축가가 설계도를 의존하는 것이 보인다.

 

그런데, 여기서 blueprint라는 객체가 바뀌어 schoolblueprint라는 것으로 바뀌었다고 치자.

그렇다면 이 Constructer 에서도 코드의 변경이 필요하다.

그러나, 앞선 포스팅에서 OCP 원칙에 대해서 설명하였다.

소프트웨어는 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다는 것이다. 위 코드는 확장에는 열려 있으나, 그 확장이 된다면 변경도 뒤따라 오게 된다. 따라서 변경에 닫혀 있다고 볼 수 없다. 나쁜 코드이다.

 

이것을 어떻게 바꿔야 할까?

 

public class Constructor{
	
	private Blueprint blueprint;
	
	public Constructor(Blueprint blueprint) {
		this.blueprint = blueprint;
	}
	
}

 

// DI컨테이너
Constructor = new Constructor(new Blueprint());

이렇게 된다면, 만약 Blueprint가 다른 것으로 바뀌어도, 우리는 DI컨테이너만 손을 대면 된다.

 

위 예에서, 원래는 건축가는 설계도를 직접 그리고, 건물도 짓고 있었다.

허나, DI 컨테이너라는 설계가가 나타나서, 설계도를 그려주는 것이다. 이로써, 건축가는 자신이 해야하는 일만 할 수 있게 되었다.

책임이 줄었다는 것이다. 이처럼 의존관계를 외부에서 결정하여 주입하여 주면, 한 객체에게 책임이 몰리는 것을 막을 수 있다.

 

 

 

 

 

해당 글은 아직 공부중이므로, 시간 나는대로 수정하여 덧붙이겠습니다.