관리 메뉴

나만의공간

스프링 주요 개념 용어 2 - DI(Dependency Injection) 본문

IT/Spring

스프링 주요 개념 용어 2 - DI(Dependency Injection)

밥알이 2014. 6. 9. 17:20

아래 내용은 해당 블로그에서 가져왔습니다.

http://blog.naver.com/acatholic/90176623916


DI(Dependency Injection)

-> 결론적으로 타이트한 의존관계로 묶여 있던 각 클래스들을 느슨하게 묶어 주는 것.

java 의 소스 코드 레벨에서의 의존성을 줄이는것임.

DI 를 쓰면 코드가 훨씬 간단해지고 쉬워지고 단위 모듈 테스트도 쉬워짐

 

1. Coupling 

: 두 개의 클래스가 서로 객체 생성하면서 관계, 의존성을 갖게 되는 것.

 

커플링시 스프링은 DI 라 명명된 방법을 써서 :POJO 대로 사용하기 편하게 만든다.

(스프링이 커플링을 느슨하게 한다)

POJO 는 단순하지만 아직도 파워풀함.

스프링이 POJO 를 강화하는 한 가지 방법이 DI(Dependency Injection)를 이용해서 

POJO 자신들을 조립하는 것이다.

 

2. 하나의 클래스 A 에서 다른 클래스B 의 변수를 선언한 후 A의 생성자 등에서 B 객체를 생성할 때,

 

A 클래스가 Tightly coupled to B class 또는 Highly coupled to B class 되었다고 하고 , A 클래스가 B 클래스에 의존성을 갖게 된다. B 클래스가 없으면 A 클래스는 컴파일조차 되지 않으므로 의존성을 갖게 되는 것이고

이 상황을 (be) inject(ed) dependency 라 표현한다.

이것을 명사화(Dependency Injection) 한 것으로 생각하면 될 듯 함.

의존(Dependency) 하는 객체를 조립기가 삽입 (Inject) 해주기 때문에 이 방식을 DI 패턴이라고 부른다(조립기인 스프링 프레임웍이 xml 파일을 읽어서 특정 클래스 객체를 생성해 준다)

 

3. 방법

- 위의 B 클래스 객체를 A 클래스B에서 생성하지 않음. 

- B 클래스와 같이 A 클래스 안에서 호출되는 클래스들의 공통되는 메소드들을 선언한 I_B 인터페이스 작성.

- I_B 인터페이스를  implements 한 B 클래스, C 클래스,  ...등을 작성.

- A 클래스의 생성자에서  I_B 인터페이스를 매개변수에 받아서 처리하도록 코딩.

- xml 파일안에 B , C클래스가 A 클래스의 생성자 안에서 객체 생성되어야 함을 노티해 주는 형식으로

구현

 

 

예를 들면 아래처럼 

DamselRescuingKnight 클래스의 생성자에서 RescueDamselQuest 클래스의 객체를 

생성하는게 아니라

 

//Damsel : 소녀, 소녀구출기사 클래스

package com.springinaction.knights;

public class DamselRescuingKnight implements Knight {

private RescueDamselQuest quest;

 

public DamselRescuingKnight() {

quest = new RescueDamselQuest();

}

public void embarkOnQuest() throws QuestException {

quest.embark();

}

 

}

 

 

아래 BraveKnight 클래스처럼 Quest 인터페이스(존재한다고 가정)를 매개변수로 받고

 

package com.springinaction.knights;

public class BraveKnight implements Knight {

private Quest quest;

public BraveKnight(Quest quest) {

this.quest = quest;

}

public void embarkOnQuest() throws QuestException {

quest.embark();

}

}

 

 

아래처럼 knight.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-3.0.xsd">

<bean id="knight" class="com.springinaction.knights.BraveKnight">

<constructor-arg ref="quest" />  <!--  코드단에서 객체 생성하지 않고 스프링이 객체생성하도록 하고 싶은 클래스라고 bean 태그이용해 알려줌, 이 xml 파일에서 BraveKnight 클래스는 knight 로 참조하겠다고 알려준다, 또 BraveKnight 클래스의 생성자에는 이 xml 파일에서 quest 로 참조하는 클래스를 매개변수로 받을 것임을 스프링에게 알려준다. -->

</bean>

<bean id="quest"

class="com.springinaction.knights.SlayDragonQuest" />

</beans>

 

** 결국 각 클래스의 의존성을 xml 파일안에 정의해 놓고 스프링 프레임웍이 객체 생성하고 

관리하게 하는 것.

 

위에서 

bean 엘리먼트의 class 속성값이 실제 클래스 이름이고 id="knight" 는 그냥 레퍼런스.

constructor-arg 엘리먼트의 ref 속성 값이 또 다른 bean 엘리먼트의 id(레퍼런스) <-- 위 예제의 경우에는 quest.

 

요 또 다른 bean  엘리먼트의 class 속성에 지정된 클래스가 com.springinaction.knights.BraveKnight 클래스의 생성자의 매개변수로 들어가는 클래스임.

위에서는 com.springinaction.knights.SlayDragonQuest(용을죽여달라는요청) 클래스임

 

 

그리고 실제 xml 파일을 로딩해서 파싱하고 실행하는 파일은 아래와 같이 작성하면 됨.

 

 

package com.springinaction.knights;

import org.springframework.context.ApplicationContext;

import org.springframework.context.support.ClassPathXmlApplicationContext;

 

public class KnightMain {

public static void main(String[] args) {

ApplicationContext context =

new ClassPathXmlApplicationContext("knights.xml");//위에서 작성한 knight.xml 로딩

Knight knight = (Knight) context.getBean("knight");//knight bean 을 획득. 

knight.embarkOnQuest();

}

 

 

아래는 http://joke00.tistory.com/160 에 있는 내용

 


스프링에는 중요한 개념중에 DI 과 AOP 개념이 있는데, 먼저 DI 개념에 대해서 간략하게 숙지해 보도록하자.

DI 란 ?

=> 객체 간의 의존관계를 객체 자신이 아닌 외부의 조립기가 수행해 준다는 개념

DI 패던을 적용할 경우 클래스는 의존하는 객체를 전달받기 위한
설정 메서드 (setter method) 나 생성자를 제공할 뿐  직접 의존하는 클래스를 찾지 않는다. 
의존(Dependency) 하는 객체를 조립기가 삽입 (Inject) 해주기 때문에 이 방식을 DI 패턴이라고 부른다. 
DI 패턴 사용시 단위 테스트가 가능하다.
단위테스트는 코드의 품질을 향상시키고 개발속도를 증가시키는데 도움이 되기 때문에, 
DI 패턴이 단일테스트를 진행하는데 도움을 준다.
DI 패턴을 적용하려면 각 객체들을 조립해 주는 조립기가 필요하다.
조립기를 직접 만들기 보다는 DI 패턴을 지원해 주는 프레임워크를 사용하는 것이 좋다
(그래서 조립기로 쓰일 것이 바로 Spring 프레임워크이다)



DI 패턴에는 2가지 방식이 존재

1. 생성자 <constructor-arg>
2. 메소드 <property> 

더 자세한 내용은 책을 찾아보도록 하자.


스프링은 각 개체를 빈(bean) 으로 관리한다.
<beans> 태그는 스프링 설정파일의 루트태그 이며 
<bean> 태그는 스프링에 관리할 하나의 객체를 설정하는데 사용한다.
<bean> 태그의 name 속성 : 빈의 이름, class  : 속성이 생성될 객체의 클래스 타입

 

 아래는 http://projectm.tistory.com/2 에 있는 내용 : 티스토리에 로그인해야 한다고 해서 퍼간다는 댓글 못 남겼음. 혹시 주인장님 보고 계시면 죄송합니다. 용서해 주십쇼.

 

DI의 개념

일반적으로 어플리케이션은 컴포넌트들을 조합하여 이루어진다고 가정하자. 

컴포넌트란 소프트웨어 모듈로서 더 이상의 수정이 없이도 사용할 수 있는 라이브러리를 뜻한다. 이 때, 어플리케이션을 구성하는 과정에서 각 컴포넌트들 사이의 결합은 서로가 서로를 호출하는 형태로 이루어진다.

이러한 컴포넌트들간의 연관관계(혹은 Dependency)는 여러가지 문제점을 가진다. 
이러한 문제점은 시스템의 구동과정에서의 문제를 의미하는 것이 아니라, 개발과정에서의 여러가지 형태의 변경과정, 유지, 보수, 업그레이드 과정에서 발생하는 문제를 의미한다.

여러 컴포넌트들 가운데 특정 컴포넌트를 변경하려고 하면, 혹은 교체하려고 하면, 이 컴포넌트와 연관된 컴포넌트들에도 변경이 불가피하게 된다.


 


 



발상의 전환점은 바로 여기에 있다. 
그렇다면, 컴포넌트들 간의 연관관계를 더 느슨하게 혹은 외부에서 할 수는 없을까? 
그렇다. 연관관계를 컴포넌트들간에 이루어지도록 하지 말고, 컴포넌트들을 가지는 컨테이너가 연관관계를 규정하도록 하자. 
그렇게 하면, 컴포넌트들 사이에는 연관관계가 발생하지 않으므로 위에서 언급된 문제들이 해결될 것이다. 

이것이 바로 Inversion of Control / Dependency Injection의 핵심 개념이다.

 


 

그림1과 그림2를 비교해보면, 그림1에서는 클래스 CA가 클래스 IBImpl을 생성한다. 

IBImpl 클래스가 다른 클래스로 변경되면 CA에도 변경이 필요하게 된다. 

반면에, 그림2에서 클래스 CA는 클래스 IBImpl과 연관관계가 없다. 단지, 인터페이스 IB만을 호출한다. 그러므로 IBImpl 클래스가 다른 클래스로 변경되어도 CA에 변경이 가해질 일이 없게 된다.


즉, DI가 갖게 되는 장점은 아래와 같다.

  • 코드의 단순화
  • 종속적인 코드의 최소화 (인프라 코드와 비즈니스 코드 분리)
  • 어플리케이션을 더 쉽게 유지관리


이렇게 컨테이너에게 제어권이 넘어간것을 IoC라고 하며, 용어자체의 문제로 인해 보통은 DI라고 부르는게 요즘의 추세라고 본다.

기존 코드가 코드안에서 객체의 생성과 소멸을 했다고 한다면, DI 개념 안에서는 객체를 생성, 파괴와 객체간의 의존관계를 컨테이너에 의해서 제어함한다는것이 핵심인것이다. 컨테이너가 객체를 제어하는 방식은 XML이 될 수도 있고 Properties로도 할 수도 있다. 스프링에서는 간단한 컨벤션 룰을 통해서 XML로 관리한다고 보면 될 것이다.


IoC의 구현방법에는 두가지가 있다. 

첫째는 Dependency Lookup이다. 
이 것은 컨테이너가 callback을 통해서 제공하는 lookup context를 이용해서 필요한 리소스나 오브젝트를 얻는 방식이다.
EJB와 Apache Avalon의 구현방법이다. 

둘째는 Dependency Injection이다. 우리가 해야할 부분은 바로 이 DI 부분이다. 
이것은 비즈니스 오브젝트에 look up 코드를 사용하지 않고 컨테이너가 직접 의존구조를 오브젝트에 설정할 수 있도록 지정 해주는 방법이다.
DI는 다시 Setter Injection과 Constructor Injection으로 나뉜다.

Dependency Lookup은 JNDI등을 이용하는데 오브젝트간에 decoupling을 해주는 면에서 장점이 있기는 하다. 
하지만 이렇게 만들어진 오브젝트는 컨테이너 밖에서 실행 할 수 없고 JNDI외의 방법을 사용할 경우 JNDI관련 코드를 오브젝트내에 일일히 변경해 줘야 하며 테스트하기 매우 어렵고 코드양이 매우 증가하고 Strong typed가 아니므로 Object로 받아서 매번 Casting해야 하고 (그래서 primitive type은 wrapper class를 써야 하고) NamingException같은 checked exception을 처리하기 위해서 exception처리구조가 매우 복잡해지는 단점이 있다. 


Dependency Injection은 각 오브젝트가 자신이 의존적인 resource와 collaborator에 대한 lookup의 책임을 가지지 않고 대신 컨테이너가 그 일을 담당하고 오브젝트 내에 주입해주는 방식이다.

따라서 lookup과 관련된 코드들이 오브젝트 내에서 완전히 사라지고 컨테이너에 의존적이지 않은 코드를 작성할 수 있다.


이는 오브젝트가 컨테이너의 존재여부를 알 필요조차도 없기 때문이다. 또 특별한 인터페이스 구현나 클래스의 상속의 필요가 없다.

 

 


Comments