<div id="readability-page-1" class="page"><div><h2 id="di--ioc"><a href="#di--ioc" aria-label="di ioc permalink"></a>DI / IoC</h2>
<h2 id="의존성-주입dependency-injection"><a href="#%EC%9D%98%EC%A1%B4%EC%84%B1-%EC%A3%BC%EC%9E%85dependency-injection" aria-label="의존성 주입dependency injection permalink"></a>의존성 주입(Dependency Injection)</h2>
<h3 id="정의"><a href="#%EC%A0%95%EC%9D%98" aria-label="정의 permalink"></a>정의</h3>
객체를 직접 생성하는 것이 아니라, 외부에서 생성한 후 주입을 하는 방법이다.
<h3 id="di의-가장-큰-목적"><a href="#di%EC%9D%98-%EA%B0%80%EC%9E%A5-%ED%81%B0-%EB%AA%A9%EC%A0%81" aria-label="di의 가장 큰 목적 permalink"></a>DI의 가장 큰 목적</h3>
<ul>
<li>객체 간의 결합도를 느슨하게 하고(의존성을 낮추고) 확장이 용이하게 하여 객체지향적 프로그래밍을 가능하게 한다.</li>
<li>스프링에서는 <code>Spring 컨테이너</code>, <code>IoC 컨테이너</code>라는 개념을 사용한다. 컨테이너는 인스턴스의 생명주기를 관리하며, 생성된 인스턴스에게 추가적인 기능을 제공한다.</li>
<li>즉 컨테이너는 사용자가 작성한 코드의 처리과정을 위임받은 독립적인 존재다. 이 때문에 제어권이 사용자에게 있는 것이 아니라 컨테이너에게 있게되는 즉, <code>Inversion Of Control</code>이 발생하게 되는 것이다. 적절한 설정만 컨테이너에 되어있다면 프로그래머가 작성한 코드를 스스로 참조하여 객체의 생성과 소멸을 사용자 대신 컨트롤한다.</li>
</ul>
<hr>
<h3 id="의존성-주입-예시"><a href="#%EC%9D%98%EC%A1%B4%EC%84%B1-%EC%A3%BC%EC%9E%85-%EC%98%88%EC%8B%9C" aria-label="의존성 주입 예시 permalink"></a>의존성 주입 예시</h3>
<div data-language="java"><pre><code>public class Car {
	private Tire tire;
	public Car(){
	tire = new Tire();
	}
}</code></pre></div>
의존성은 new 키워드를 통해 만들어지는데, 따라서 Car는 Tire에 종속된다. 즉 Tire의 제어권은 Car에게 있다. 
<div data-language="java"><pre><code>public class Car {
	private Tire tire;
	public Car(Tire tire){
		this.tire = tire;
	}
}
public CarTest {
	Tire tire = new Tire();
	Car car = new Car(tire);
}</code></pre></div>
하지만 위와 같이 생성자를 통해 의존성을 주입한다면, Tire의 제어권이 CarTest에 있게된다. 즉 CarTest가 Tire에 의존성을 갖는다. 이처럼 의존성을 역전시켜 제어권을 직접 갖지 않는 것이 IoC이며, 의존성을 외부에서 주입시키는 것이 DI이다.
<h2 id="주입의-종류"><a href="#%EC%A3%BC%EC%9E%85%EC%9D%98-%EC%A2%85%EB%A5%98" aria-label="주입의 종류 permalink"></a>주입의 종류</h2>
<h3 id="code-classlanguage-text생성자code를-통한-의존성-주입"><a href="#code-classlanguage-text%EC%83%9D%EC%84%B1%EC%9E%90code%EB%A5%BC-%ED%86%B5%ED%95%9C-%EC%9D%98%EC%A1%B4%EC%84%B1-%EC%A3%BC%EC%9E%85" aria-label="code classlanguage text생성자code를 통한 의존성 주입 permalink"></a><code>생성자</code>를 통한 의존성 주입</h3>
<div data-language="java"><pre><code>public class Dessert {
	private final CakeService cakeService;
	private final DrinkService drinkService;
	
	@Autowired
	public Dessert(CakeService cakeService, DrinkService drinkService) {
			this.cakeService = cakeService;
			this.drinkService= drinkService;
		}
}</code></pre></div>
<h3 id="code-classlanguage-textsettercode를-통한-주입"><a href="#code-classlanguage-textsettercode%EB%A5%BC-%ED%86%B5%ED%95%9C-%EC%A3%BC%EC%9E%85" aria-label="code classlanguage textsettercode를 통한 주입 permalink"></a><code>Setter</code>를 통한 주입</h3>
<div data-language="java"><pre><code>public class Dessert {
	private final CakeService cakeService;
	private final DrinkService drinkService;
	
	@Autowired
	public void setCakeService(CakeService cakeService) {
			this.cakeService = cakeService;
	}
	@Autowired
	public void setDrinkService(DrinkService drinkService) {
			this.drinkService = drinkService;
	}
}</code></pre></div>
<h3 id="code-classlanguage-textfieldcode를-통한-주입"><a href="#code-classlanguage-textfieldcode%EB%A5%BC-%ED%86%B5%ED%95%9C-%EC%A3%BC%EC%9E%85" aria-label="code classlanguage textfieldcode를 통한 주입 permalink"></a><code>Field</code>를 통한 주입</h3>
<div data-language="java"><pre><code>public class Dessert {
	@Autowired
	private final CakeService cakeService;
	@Autowired
	private final DrinkService drinkService;
}</code></pre></div>
<h2 id="생성자-주입을-권장하는-이유"><a href="#%EC%83%9D%EC%84%B1%EC%9E%90-%EC%A3%BC%EC%9E%85%EC%9D%84-%EA%B6%8C%EC%9E%A5%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0" aria-label="생성자 주입을 권장하는 이유 permalink"></a>생성자 주입을 권장하는 이유</h2>
<h3 id="순환-참조-방지"><a href="#%EC%88%9C%ED%99%98-%EC%B0%B8%EC%A1%B0-%EB%B0%A9%EC%A7%80" aria-label="순환 참조 방지 permalink"></a>순환 참조 방지</h3>
A가 B를 참조하고, B가 다시 A를 참조하는 순환참조가 일어난다고 가정하자. <code>생성자 주입</code>의 경우 <code>BeenCurrentlyInCreationException</code>이 발생하여 애플리케이션이 구동되지 않는다.
<ul>
<li><code>setter 주입</code> : setter 주입에서는 우선 주입 받는 빈의 생성자를 호출하여 빈을 찾거나, 팩토리에 등록한다. 그 후 생성자 인자에 사용하는 빈을 찾거나 만든다. 그 이후 주입하려는 빈 객체의 setter를 호출하여 주입한다.</li>
<li><code>field 주입</code> : 수정자 주입 방법과 동일하게 먼저 빈을 생성한 뒤 어노테이션이 붙은 필드에 해당하는 빈을 찾아서 주입하는 방식이다. 즉 빈을 먼저 생성한 후 필드에 대해서 주입한다.</li>
<li><code>생성자 주입</code> : 생성자로 객체를 생성하는 시점에 필요한 빈을 주입한다. 먼저 생성자의 인자에 사용되는 빈을 찾거나 빈 팩토리에서 만든다. 그 후에 찾은 인자 빈으로 주입하려는 빈의 생성자를 호출한다. 즉 빈을 먼저 생성하는 것이 아니다.</li>
</ul>
따라서 <code>순환참조</code>는 생성자 주입에서만 문제가 된다. 객체 생성 시점에 빈을 주입하기 때문에 서로 참조하는 객체가 생성되지 않은 상태에서 그 빈을 참조하기 때문에 오류가 발생한다.
<h3 id="테스트-용이"><a href="#%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%9A%A9%EC%9D%B4" aria-label="테스트 용이 permalink"></a>테스트 용이</h3>
테스트 코드를 좀 더 편리하게 작성할 수 있다. 필드 주입같은 경우에 객체 생성만으로는 의존성을 주입할 수 없기 때문에, 테스트 코드를 작성할 때 <code>@Mock</code> 을 사용하여 주입해야한다. 하지만 생성자를 통한 주입은 객체를 생성한 뒤 생성자에 넣어주기만 하면 된다.
<h3 id="final로-선언할-수-있다"><a href="#final%EB%A1%9C-%EC%84%A0%EC%96%B8%ED%95%A0-%EC%88%98-%EC%9E%88%EB%8B%A4" aria-label="final로 선언할 수 있다 permalink"></a>final로 선언할 수 있다.</h3>
<code>필드 주입</code>과 <code>setter 주입</code>은 해당 필드를 <code>final</code>로 선언할 수 없다. 따라서 초기화 후 Bean 객체가 변경될 수 있지만, 생성자 주입의 경우에는 필드를 <code>final</code>로 선언할 수 있다. 따라서 필드 주입인 경우 null값이 되는게 가능하기 때문에 <code>NullPointerException</code> 발생 위험이 있는데, 생성자 주입은 final 변수 선언을 통해 null이 되는 것이 불가능하다.
<h3 id="의존관계-파악"><a href="#%EC%9D%98%EC%A1%B4%EA%B4%80%EA%B3%84-%ED%8C%8C%EC%95%85" aria-label="의존관계 파악 permalink"></a>의존관계 파악</h3>
생성자의 파라미터를 통해 의존관계를 한 눈에 파악할 수 있고, 리팩토링의 필요성을 얻을 수 있다. (Constructor의 파라미터가 많아짐과 동시에 하나의 클래스가 많은 책임을 떠안다는 것을 알게된다.)
출처
<a href="https://iseunghan.tistory.com/58">https://iseunghan.tistory.com/58</a>
<a href="https://madplay.github.io/post/why-constructor-injection-is-better-than-field-injection">https://madplay.github.io/post/why-constructor-injection-is-better-than-field-injection</a>
<a href="https://devfunny.tistory.com/263">https://devfunny.tistory.com/263</a></div></div>

Seulog💘

이예슬

DI / IoC
의존성 주입(Dependency Injection)
정의
객체를 직접 생성하는 것이 아니라, 외부에서 생성한 후 주입을 하는 방법이다.
DI의 가장 큰 목적
객체 간의 결합도를 느슨하게 하고(의존성을 낮추고) 확장이 용이하게 하여 객체지향적 프로그래밍을 가능하게 한다.
스프링에서는 Spring 컨테이너, IoC 컨테이너라는 개념을 사용한다. 컨테이너는 인스턴스의 생명주기를 관리하며, 생성된 인스턴스에게 추가적인 기능을 제공한다.
즉 컨테이너는 사용자가 작성한 코드의 처리과정을 위임받은 독립적인 존재다. 이 때문에 제어권이 사용자에게 있는 것이 아니라 컨테이너에게 있게되는 즉, Inversion Of Control이 발생하게 되는 것이다. 적절한 설정만 컨테이너에 되어있다면 프로그래머가 작성한 코드를 스스로 참조하여 객체의 생성과 소멸을 사용자 대신 컨트롤한다.
의존성 주입 예시
public class Car {
	private Tire tire;
	public Car(){
	tire = new Tire();
	}
}
의존성은 new 키워드를 통해 만들어지는데, 따라서 Car는 Tire에 종속된다. 즉 Tire의 제어권은 Car에게 있다. 
public class Car {
	private Tire tire;
	public Car(Tire tire){
		this.tire = tire;
	}
}
public CarTest {
	Tire tire = new Tire();
	Car car = new Car(tire);
}
하지만 위와 같이 생성자를 통해 의존성을 주입한다면, Tire의 제어권이 CarTest에 있게된다. 즉 CarTest가 Tire에 의존성을 갖는다. 이처럼 의존성을 역전시켜 제어권을 직접 갖지 않는 것이 IoC이며, 의존성을 외부에서 주입시키는 것이 DI이다.
주입의 종류
생성자를 통한 의존성 주입
public class Dessert {
	private final CakeService cakeService;
	private final DrinkService drinkService;
	
	@Autowired
	public Dessert(CakeService cakeService, DrinkService drinkService) {
			this.cakeService = cakeService;
			this.drinkService= drinkService;
		}
}
Setter를 통한 주입
public class Dessert {
	private final CakeService cakeService;
	private final DrinkService drinkService;
	
	@Autowired
	public void setCakeService(CakeService cakeService) {
			this.cakeService = cakeService;
	}
	@Autowired
	public void setDrinkService(DrinkService drinkService) {
			this.drinkService = drinkService;
	}
}
Field를 통한 주입
public class Dessert {
	@Autowired
	private final CakeService cakeService;
	@Autowired
	private final DrinkService drinkService;
}
생성자 주입을 권장하는 이유
순환 참조 방지
A가 B를 참조하고, B가 다시 A를 참조하는 순환참조가 일어난다고 가정하자. 생성자 주입의 경우 BeenCurrentlyInCreationException이 발생하여 애플리케이션이 구동되지 않는다.
setter 주입 : setter 주입에서는 우선 주입 받는 빈의 생성자를 호출하여 빈을 찾거나, 팩토리에 등록한다. 그 후 생성자 인자에 사용하는 빈을 찾거나 만든다. 그 이후 주입하려는 빈 객체의 setter를 호출하여 주입한다.
field 주입 : 수정자 주입 방법과 동일하게 먼저 빈을 생성한 뒤 어노테이션이 붙은 필드에 해당하는 빈을 찾아서 주입하는 방식이다. 즉 빈을 먼저 생성한 후 필드에 대해서 주입한다.
생성자 주입 : 생성자로 객체를 생성하는 시점에 필요한 빈을 주입한다. 먼저 생성자의 인자에 사용되는 빈을 찾거나 빈 팩토리에서 만든다. 그 후에 찾은 인자 빈으로 주입하려는 빈의 생성자를 호출한다. 즉 빈을 먼저 생성하는 것이 아니다.
따라서 순환참조는 생성자 주입에서만 문제가 된다. 객체 생성 시점에 빈을 주입하기 때문에 서로 참조하는 객체가 생성되지 않은 상태에서 그 빈을 참조하기 때문에 오류가 발생한다.
테스트 용이
테스트 코드를 좀 더 편리하게 작성할 수 있다. 필드 주입같은 경우에 객체 생성만으로는 의존성을 주입할 수 없기 때문에, 테스트 코드를 작성할 때 @Mock 을 사용하여 주입해야한다. 하지만 생성자를 통한 주입은 객체를 생성한 뒤 생성자에 넣어주기만 하면 된다.
final로 선언할 수 있다.
필드 주입과 setter 주입은 해당 필드를 final로 선언할 수 없다. 따라서 초기화 후 Bean 객체가 변경될 수 있지만, 생성자 주입의 경우에는 필드를 final로 선언할 수 있다. 따라서 필드 주입인 경우 null값이 되는게 가능하기 때문에 NullPointerException 발생 위험이 있는데, 생성자 주입은 final 변수 선언을 통해 null이 되는 것이 불가능하다.
의존관계 파악
생성자의 파라미터를 통해 의존관계를 한 눈에 파악할 수 있고, 리팩토링의 필요성을 얻을 수 있다. (Constructor의 파라미터가 많아짐과 동시에 하나의 클래스가 많은 책임을 떠안다는 것을 알게된다.)
출처
https://iseunghan.tistory.com/58
https://madplay.github.io/post/why-constructor-injection-is-better-than-field-injection
https://devfunny.tistory.com/263

DI/IoC

댓글