IoC(Inversion Of Control) / DI(Dependency Injection)
by Green Frog Developer
이 글에서는 Spring이 사용하고 있는 IoC(Inversion of Control)와 DI(Dependency Injection)에 대해서 알아볼 것이다.
IoC/DI에 대해 알아보기 전에 자바에서의 의존성이란 무엇을 의미하는지에 대해서 먼저 알아보자.
프로그래밍에서 의존성이란?
자동차와 타이어를 예로들어 의존성에 대해서 설명하겠다.
의사 코드
- 운전자(Driver)가 자동차(Car)를 생산한다.
- 자동차(Car)는 내부적으로 타이어(Tire : 다양한 종류중 하나의 타이어)를 생산한다.
자바로 표현
- new Car(); (Driver 클래스 내부)
- Car 객체 생성자에서 new KoreaTire(); (의존 관계가 일어나고 있는 부분)
의존성을 단순하게 정의하면 다음과 같다.
- 의존성은 new이다.
- new를 실행하는 Car와 KoreaTire사이에 Car가 KoreaTire에 의존한다.
결론적으로 전체가 부분에 의존한다고 표현할 수 있다.(더 깊이 들어가면 집합과 구성 관계로 구분할 수 있다.)
이러한 요구사항을 먼저 스프링을 적용하지 않은 기존 방식으로 자바 코드를 작성해 보고, 점진적으로 스프링 Annotation 방식으로 변경해 보자.
스프링 없이 의존성 주입하기
1. 생성자를 통한 의존성 주입
의사 코드
- 운전자가 타이어(다양한 종류중 하나)를 생산한다.
- 운전자가 자동차를 생산하면서 타이어를 장착한다.
자바로 표현 - 생성자 인자 이용
- Tire americaTire = new AmericaTire();
- Car car = new Car(americaTire);
기존 코드에서는 Car의 생성자에서 구체적으로 어떤 Tire를 생산할지를 결정했었다. 즉, Tire가 KoreaTire나 AmericaTire 또는 JapanTire로 바뀔 때마다 Car 생성자의 코드를 바꿔줘야 하기 때문에 개발자들은 유지보수하기 되게 힘들어진다. 그래서 이러한 코드를 유연성이 떨어지는 코드라고 부른다.
변경된 코드에서는 운전자가 직접 AmericaTire를 생산해서 자동차에 장착하게 만들기 때문에 Car의 생성자는 어떤 타이어를 장착할까를 더는 고민하지 않아도 된다. 코드의 유연성이 늘어난다.
즉, Tire 인터페이스를 상속한 클래스의 의존성을 주입하면 나중에 어떤 새로운 타이어 브랜드가 생겨도 각 타이어 브랜드들이 Tire 인터페이스를 구현한다면 Car.java 코드를 변경할 필요 없이 사용할 수 있기 때문에 코드의 확장성과 유지보수성이 좋아진다.
2. 속성을 통한 의존성 주입
의사코드
- 운전자가 타이어를 생산한다.
- 운전자가 자동차를 생산한다.
- 운전자가 자동차에 타이어를 장착한다.
자바로 표현 - 속성 접근자 메서드 사용
- Tire koreatire = new KoreaTire();
- Car car = new Car();
- car.setTire(koreatire);
위에서 볼 수 있듯이 이번에는 속성을 통해서 의존성을 주입해 보았다. 이러한 방법을 사용하게 되면 운전자가 원할 때 Car의 Tire를 교체할 수 있게되기 때문에 코드가 현실세계에 좀 더 가까워 진다.
프로그래밍 세계에서는 생성자를 통해 의존성을 주입하는 방법과 속성을 통해 의존성을 주입하는 방법 중 어느 쪽이 더 좋은가에 대한 의견이 분분했었는데, 최근에는 속성을 통한 의존성 주입보다는 생성자를 통한 의존성 주입을 선호하는 사람이 더 많다. 실세계에서라면 십년 가까이 타게 되는 차를 사고 타이어를 교체하는 일이 빈번할 수 있지만 프로그램에서는 한번 주입된 의존성을 계속 사용하는 경우가 더 일반적이기 때문이다.
스프링을 통한 의존성 주입
1. 스프링 설정 파일(XML) 사용
의사 코드 (종합 쇼핑몰의 역할은 Spring Framework이다.)
- 종합 쇼핑몰에 타이어와 자동차를 입점시킨다.
- 운전자가 종합 쇼핑몰에서 타이어를 구매한다.
- 운전자가 종합 쇼핑몰에서 자동차를 구매한다.
- 운전자가 자동차에 타이어를 장착한다.
자바로 표현 - 속성 메서드 사용
- ApplicationContext context = new ClassPathXmlApplicationContext(“expert002.xml”, Driver.class);
- Tire tire = (Tire)context.getBean(“tire”);
- Car car = (Car)context.getBean(“car”);
- car.setTire(tire);
Spring을 도입하면 이전 코드에서 Driver 클래스만 바뀌고 스프링 설정 파일(XML)만 추가되는 것이지 사실 Spring을 사용하지 않을때와 거의 비슷하다.
스프링을 사용한 후 변경된 시퀀스 다이어그램에 대해서 살펴보자.
기존 다이어그램과 비교해서 달라진 곳은 종합 쇼핑몰(Spring Framework)가 들어온 것 외에는 달라진 부분이 없다. 운전자가 타이어, 자동차를 직접 생산하던 시스템에서 종합 쇼핑몰을 통해 구매하는 형태로 바뀌었다. 즉, 현실세계와 더욱 유사해졌다.
Driver 클래스 내부의 코드를 살펴보자.
package expert001_01;
// 종합 쇼핑몰(Spring Framework)에 대한 정보를 가지고 있는 패키지
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class Driver {
public static void main(String[] args) {
// 종합 쇼핑몰에 대한 정보
ApplicationContext context = new ClassPathXmlApplicationContext("expert001.xml");
// 종합 쇼핑몰에서 상품에 해당하는 Car 구매
Car car = context.getBean("car",Car.class);
// 종합 쇼핑몰에서 상품에 해당하는 Tire 구매
Tire tire = context.getBean("tire", Tire.class);
//운전자가 자동차에 타이어를 장착
car.setTire(tire);
System.out.println(car.getTireBrand());
}
}
그리고 한 가지 더 필요한 것이 있다. 아무리 종합 쇼핑몰(Spring Framework)이라고 하지만 상품(Bean)이 입점돼 있어야만 판매할 수 있을 것이다. 입점된 상품에 대한 정보는 `ClassPathXmlApplicationContext` 클래스 생성자의 인자로써 주어진 xml 파일(expert001.xml)에 저장되어 있다.
<종합 쇼핑몰(Spring Framework) 판매 목록(Bean)등록하기 위한 XML 파일>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="tire" class="expert001_01.KoreaTire" ></bean>
<bean id="americaTire" class="expert001_01.AmericaTire"></bean>
<bean id="car" class="expert001_01.Car"></bean>
</beans>
위의 예제에서는 3개의 상품(Bean)을 등록했다. 상품을 등록할 때는 bean 태그를 이용해 등록한다. 이 때 각 상품을 구분하기 위한 id 속성과 그 상품을 어떤 클래스를 통해 생산(인스턴스화)해야 할지 나타내는 class 속성을 함께 지정하면 된다.
각 상품을 만들어서 종합쇼핑몰(Spring Framework)에 등록해서 사용하는 순간까지를 선긋기로써 표현한 그림은 다음과 같다.
KoreaTire.java가 XML 파일에서 id=tire인 bean 태그와 연결돼 있고, 다시 Driver.java의 main() 메서드 안의 코드인 context.getBean("tire", Tire.class)와 연결돼 있는 것을 볼 수 있다.
즉, KoreaTire라고 하는 상품이 tire라는 이름으로 진열돼 있고, 구매(getBean)할 수 있다.
위의 설명들을 참고해서 스프링을 도입해서 얻을 수 있는 가장 큰 이득에 대해서 생각해보자.
스프링을 도입해서 얻을 수 있는 가장 큰 이득을 꼽으라면 자동차의 타이어 브랜드를 변경할 때 그 무엇도 재컴파일/재배포하지 않아도 XML 파일만 수정하면 프로그램의 실행결과를 바꿀 수 있다는 것이다.
Driver.java의 Tire tire = context.getBean("tire", Tire.class); 부분이 타이어를 구매하는 부분인데, 자바 코드 어디에서도 KoreaTire 클래스나 AmericaTire 클래스를 지칭하는 부분이 없다. 바로 expert001.xml에 이에 해당하는 내용이 있기 때문이다. 즉, expert001.xml에서 해당하는 부분의 class를 변경하면 재컴파일/재배포하지 않아도 프로그램의 실행결과를 바꿀 수 있다. 실로 엄청난 것이다!!
2. 스프링 설정 파일(XML)에서 속성 주입
의사 코드 - 점점 더 현실 세계를 닮아가고 있다.
- 운전자가 종합 쇼핑몰에서 자동차를 구매 요청한다. (Driver)
- 종합 쇼핑몰은 자동차를 생산한다. (XML)
- 종합 쇼핑몰은 타이어를 생산한다. (XML)
- 종합 쇼핑몰은 자동차에 타이어를 장착한다. (XML)
- 종합 쇼핑몰은 운전자에게 자동차를 전달한다. (Spring Framework)
자바로 표현
- ApplicationContext context = new ClassPathXmlApplicationContext(“expert001.xml”);
- Car car = context.getBean(“car”, Car.class);
XML로 표현
- <bean id=”koreaTire” class=”expert001.KoreaTire”></bean>
- <bean id=”americaTire” class=”expert001.AmericaTire”></bean>
- <bean id=”car” class=”expert001.Car”><property name=”title” ref=”koreaTire”></property></bean>
XML 파일에서 property는 Driver.java에서 car.setTire(tire);라고 하던 부분을 XML 파일의 property 태그를 이용해 대체하는 것이다.
설계가 변경된 Driver.java클래스의 코드를 참고해 보자.
package expert001;
// 종합 쇼핑몰(Spring Framework)에 대한 정보를 가지고 있는 패키지
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
class Driver {
public static void main(String[] args) {
// 종합 쇼핑몰에 대한 상품 입점
ApplicationContext context = new ClassPathXmlApplicationContext("expert001.xml");
// 종합 쇼핑몰에서 상품에 해당하는 Car 구매
Car car = context.getBean("car",Car.class);
System.out.println(car.getTireBrand());
}
}
스프링 설정 파일(XML)은 다음과 같다.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="koreaTire" class="expert001.KoreaTire" ></bean>
<bean id="americaTire" class="expert001.AmericaTire"></bean>
<bean id="car" class="expert001.Car">
<property name="tire" ref="koreaTire"></property>
</bean>
</beans>
위 코드를 기반으로 줄긋기 그림으로 표시하면 다음과 같다.
1번 선(주황색)은 코드에서 Car를 구매하는 부분이므로 자바 코드 파일에 그대로 남겨둬야 한다. Tire tire와 id가 koreaTire인 Bean 태그를 잇는 2번 선(초록색)은 타이어를 구매하는 부분이다. id=”koreaTire”와 ref=”koreaTire”를 잇는 내부의 3번 선(파란색)은 코리아 타이어를 자동차의 타이어 속성에 결합하는 부분이다.car.setTire(tire) 메서드와 property 태그를 잇는 4번 선(빨강색)은 car의 tire속성을 설정하는 부분이다.
JUnit 테스트 케이스는 다음과 같다.
import expert001.Car;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import static org.assertj.core.api.Assertions.assertThat;
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("expert001.xml")
public class CarTest {
@Autowired
Car car;
@Test
public void 자동차_코리아타이어_장착_타이어브랜드_테스트() {
assertThat("장착된 타이어: 코리아 타이어").isEqualTo(car.getTireBrand());
}
}
3. @Autowired를 통한 속성 주입
import org.springframework.beans.factory.annotation.Autowired;
@Autowired
Tire tire;
import문 하나와 @Autowired 애노테이션을 이용하면 설정자 메서드(setter, property태그)를 이용하지 않고도 종합쇼핑몰인 스프링 프레임워크가 설정 파일을 통해서 메서드 대신 속성을 주입해준다.
변경된 스프링 설정 파일은 다음과 같다.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework/schema/context/spring-context-3.1.xsd">
<context:annotation-config/>
<bean id="tire" class="expert001.KoreaTire"></bean>
<bean id="americaTire" class="expert001.AmericaTire"></bean>
<bean id="car" class="expert001.Car"></bean>
</beans>
id가 car인 bean의 내부 property태그는 @Autowired를 통해 car의 property를 자동으로 엮어줄 수 있으므로 생략이 되었다.
@Autowired의 의미는 스프링 설정 파일을 보고 자동으로 속성의 설정자 메서드(Setter, Property태그)에 해당하는 역할을 해주겠다는 의미이다. 스프링의 @Autowired는 id 매칭보다 type 매칭이 우선이다. 따라서 같은 타입을 구현한 클래스가 여러 개 있다면 그때 bean 태그의 id로 구분해서 매칭하게 되는 것이다. 하지만 id로 구분해서 매칭하는 것 보다 type로 구분해서 매칭하는 것이 개발자의 유지보수들의 더 어렵게 하기 때문에 항상 bean 태그의 id속성을 작성하는 습관을 들이자.
변경된 Car 클래스는 다음과 같다.
package expert001;
import org.springframework.beans.factory.annotation.Autowired;
public class Car {
@Autowired
Tire tire;
public String getTireBrand() {
return "장착된 타이어: " + tire.getBrand();
}
}
4. @Resource를 통한 속성 주입
의사 코드
- 운전자가 종합 쇼핑몰에서 자동차를 구매 요청한다.
- 종합 쇼핑몰은 자동차를 생산한다.
- 종합 쇼핑몰은 타이어를 생산한다.
- 종합 쇼핑몰은 자동차에 타이어를 장착한다.
- 종합 쇼핑몰은 운전자에게 자동차를 전달한다.
@Autowired를 @Resource로 바꾸면 변경된 Car 클래스는 다음과 같다.
package expert001;
import javax.annotation.Resource;
public class Car {
@Resource
Tire tire;
public String getTireBrand() {
return "장착된 타이어: " + tire.getBrand();
}
}
위 예제에서는 정말 @Autowired를 @Resource로 바뀐것 밖에 없다. 그렇다면 왜 @Autowired를 붙이면 될 것을 @Resource로 바꾸었는가?
@Autowired는 스프링 어노테이션이고 @Resource는 자바 어노테이션이다. 스프링 프레임워크를 사용하지 않는다면 @Autowired는 사용할 수 없고 @Resource만을 사용해야 한다. 그리고 @Autowired의 경우 type과 id가운데 매칭 우선순위는 type이 높다. @Resource의 경우 type과 id가운데 매칭 우선순위는 id가 높다. 즉, @Resource의 경우 id로 매칭할 Bean을 찾지 못한 경우 type으로 매칭할 Bean을 찾게 된다.
참조 : 스프링 입문을 위한 자바 객체 지향의 원리와 이해(저자: 김종민)
Subscribe via RSS