What we have to do is to be forever curiously
testing new opinions and courting new impressions

우리가 해야 할 일은 끊임없이 호기심을 갖고
새로운 생각을 시험해보고 새로운 인상을 받는 것

의존성 주입(DI)에 대해

2022-12-09

DI에 대하여

DI란

DI 필요성

DI 방법

생성자 주입

DI란

정의

DI(Dependency Injection, 의존성 주입)란 외부에서 두 객체 간의 관계를 결정해주는 디자인 패턴

인터페이스를 사이에 두어 클래스 레벨에서는 의존관계가 고정되지 않도록 하고, 런타임 시에 관계를 동적으로 주입하여 유연성을 확보하고 결합도를 낮출 수 있음

의존성이란?

한 객체가 다른 객체를 사용하는 경우를 의미

예를 들어 아래와 같이 한 객체가 다른 객체를 규정하고 있을 때, 우리는 Family 객체가 Mother 객체에 의존성이 있다고 표현

public class Family {
    private Mother mom;
}

즉, 의존성 주입은 두 객체 간 관계(의존성)를 맺는 것을 의미

DI 필요성

의존성 주입을 사용하지 않는 클래스는 다음과 같은 문제로 낮은 객체지향성을 가짐

두 클래스가 강하게 결합 : 클래스가 서로 강하게 결합되어 있어서 기존에 형성된 클래스에서 다른 멤버 변수를 사용하고 싶다면, 기존에 형성된 클래스의 변경이 불가피 → 유연성이 떨어짐
객체들 간의 관계가 아니라 클래스 간 관계 형성 : 올바른 객체지향을 추구하려면 클래스 간 관심사 분리를 통해 의존성을 낮춰야 함

DI를 통한 문제해결

객체지향 언어의 특징으로 다형성을 이용하면 클래스 간 강한 결합을 느슨하게 만들고, 클래스 간 관심사 분리를 통한 의존성을 낮추는 게 가능

추상 클래스를 이용하여 상속하는 것도 다형성을 이용하는 좋은 방법이지만, 상속은 제약이 많고, 확장성이 떨어짐

그래서 인터페이스를 이용하여 구현하는 방식이 다형성을 이용하면서도 확장성이 높음

클래스 간 관계를 추상화하여 공통되는 부분을 인터페이스로 만들고, 인스턴스 객체를 생성할 당시에 외부에서 의존성을 주입해주는 DI방식으로 객체지향 설계 가능

위 역할을 해주는 것이 Spring이라는 DI 컨테이너

Spring Framework에서는 애플리케이션 실행 시점에 필요한 객체(bean)을 생성하고, 한 객체를 다른 객체로 주입하여 의존성을 형성하는 작업을 실행

위와 같이 어떤 객체를 사용할지에 대한 책임이 프레임워크에게 넘어갔고, 주입받는 객체를 수동적으로 사용하게 되는 것을 IoC(Inversion of Control, 제어의 역전)라 함

DI 방법

생성자 주입(Constructor Injection)

생성자 주입(Constructor Injection)은 생성자를 통해 의존 관계를 주입하는 방법

생성자 주입은 생성자의 호출 시점에 1회 호출 되는 것이 보장

주입받은 객체가 변하지 않거나, 반드시 객체의 주입이 필요한 경우에 강제하기 위해 사용

Spring에서는 아래와 같이 생성자가 1개만 있을 경우에 @Autowired를 생략해도 주입이 가능하도록 편의성을 제공

@Service
public class UserService {

    private UserRepository userRepository;
    private MemberService memberService;

    public UserService(UserRepository userRepository, MemberService memberService) {
        this.userRepository = userRepository;
        this.memberService = memberService;
    }
}

수정자 주입(Setter 주입, Setter Injection)

수정자 주입(Setter 주입, Setter Injection)은 필드 값을 변경하는 Setter를 통해서 의존 관계를 주입하는 방법

Setter 주입은 생성자 주입과 다르게 주입받는 객체가 변경될 가능성이 있는 경우에 사용

@Service
public class UserService {

    private UserRepository userRepository;
    private MemberService memberService;

    @Autowired
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Autowired
    public void setMemberService(MemberService memberService) {
        this.memberService = memberService;
    }
}

위의 예제에서는 bean이 존재하지 않을 경우(@Autowired로 주입할 대상이 없는 경우)에는 오류가 발생

@Autowired(required = false)를 통해 주입할 대상이 없어도 동작하게 설정 가능

스프링 초기에는 getX, setX 등 프로퍼티를 기반으로 하는 자바 기본 스펙 때문에 수정자 주입이 자주 사용

but, 시간이 지나면서 점차 수정자 주입이 아닌 다른 방식이 주목

필드 주입(Field Injection)

필드 주입(Field Injection)은 필드에 바로 의존 관계를 주입하는 방법

IntelliJ에서 Field Injection 사용하면 Field injection is not recommended이라는 경고 문구가 발생

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;
    @Autowired
    private MemberService memberService;
}

필드 주입을 이용하면 코드가 간결해져서 과거에 상당히 많이 이용되었던 방법

하지만 필드 주입은 외부에서 접근이 불가능하다는 단점이 존재

테스트 코드의 중요성이 부각 → 필드의 객체를 수정할 수 없는 주입방식이므로 거의 사용되지 않음

일반 메소드 주입(Method Injection)

일반 메소드를 통해 의존 관계를 주입하는 방법

수정자 주입을 사용하면 한 번에 여러 필드를 주입 받을 수 있도록 메소드를 작성

거의 사용되지 않음

생성자 주입

최근에는 Spring을 포함한 DI 프레임워크의 대부분이 다음과 같은 이유들로 생성자 주입 방식을 권장

객체의 불변성 확보

수정자 주입이나 일반 메소드 주입을 이용하면 불필요하게 수정의 가능성으로 인해 유지보수가 불편

→ 생성자 주입 방식을 통해 변경의 가능성을 배제하고 불변성을 보장(권장)

테스트 코드의 작성

테스트가 특정 프레임워크에 의존하는 것은 침투적이므로 좋지 못함

가능한 순수 자바로 테스트를 작성하는 것이 가장 좋음

생성자 주입이 아닌 다른 주입으로 작성된 코드는 순수한 자바 코드로 단위 테스트를 작성하기 어려움

다음과 같은 UserService에 대해 단위 테스트를 하고자 한다.

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;
    @Autowired
    private MemberService memberService;

    public void register(String name) {
        userRepository.add(name);
    }
}

순수 자바 테스트 코드를 작성하면 다음과 같다.

public class UserServiceTest {

    @Test
    public void addTest() {
        UserService userService = new UserService();
        userService.register("MangKyu");
    }
}

위의 테스트 코드는 Spring 위에서 동작하지 않으므로 의존 관계 주입이 되지 않을 것이고, userRepository가 null이 되어 add 호출 시 NPE가 발생할 것

이를 해결하기 위해 Setter를 사용하면 변경가능성을 열어두게 되는 단점이 생김

반대로 테스트 코드에서 @Autowired를 사용하기 위해 스프링을 사용하면 단위 테스트가 아닐 뿐만 아니라, 컴포넌트들을 등록하고 초기화하는 시간 때문에 테스트 비용이 증가

반면에 생성자 주입을 사용하면 컴파일 시점에 객체를 주입받아 테스트 코드를 작성할 수 있으며, 주입하는 객체가 누락된 경우 컴파일 시점에 오류를 발견할 수 있음

final 키워드 작성 및 Lombok과의 결합

생성자 주입을 사용하면 필드 객체에 final 키워드를 사용할 수 있으며, 컴파일 시점에 누락된 의존성을 확인 가능

반면에 다른 주입 방법들은 객체의 생성(생성자 호출) 이후에 호출되므로 final 키워드를 사용할 수 없음

또한 final 키워드를 붙이면 Lombok과 결합되어 코드를 간결하게 작성 가능

Spring과 같은 DI 프레임워크는 Lombok과 결합하여 간결하고 강력한 코드를 작성 가능

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;
    private final MemberService memberService;

    public void register(String name) {
        userRepository.add(name);
    }
}

Spring이 생성자가 1개인 경우 @Autowired를 생략할 수 있도록 도와주고 있으며, 해당 생성자를 Lombok으로 구현하였기 때문

스프링에 비침투적인 코드 작성

필드 주입을 사용하려면 @Autowired를 이용해야 하는데, 이것은 스프링이 제공하는 어노테이션

@Autowired를 사용하면 다음과 같이 UserService에 스프링 의존성이 침투

import org.springframework.beans.factory.annotation.Autowired;
// 스프링 의존성이 UserService에 import되어 코드로 박혀버림

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;
    @Autowired
    private MemberService memberService;
}

프레임워크는 유행이 바뀔 수 있어 일시적이므로 핵심 코드에 스프링 문법이 박혀버리는 것은 바람직하지 않음

생성자 주입방식으로 스프링 어노테이션 없이 코드가 작성되면 더욱 유연성이 높은 코드

순환 참조 에러 방지

생성자 주입을 사용하면 애플리케이션 구동 시점(객체의 생성 시점)에 순환 참조 에러를 예방 가능

예를 들어 다음과 같이 필드을 사용해 서로 호출하는 코드가 있다.

@Service
public class UserService {

    @Autowired
    private MemberService memberService;
    
    @Override
    public void register(String name) {
        memberService.add(name);
    }
}

UserSerivce가 이미 MemberService에 의존하고 있는데, MemberService 역시 UserService에 의존

@Service
public class MemberService {

    @Autowired
    private UserService userService;

    public void add(String name){
        userService.register(name);
    }
}

위의 두 메소드는 서로를 계속 호출할 것이고, 메모리에 함수의 CallStack이 계속 쌓여 StackOverflow 에러가 발생하게 될 것

Caused by: java.lang.StackOverflowError: null
	at com.example.user.MemberService.add(MemberService.java:20) ~[main/:na]
	at com.example.user.UserService.register(UserService.java:14) ~[main/:na]
	at com.example.user.MemberService.add(MemberService.java:20) ~[main/:na]
	at com.example.user.UserService.register(UserService.java:14) ~[main/:na]

이러한 문제를 발견하지 못하고 서버가 운영되다가 도중에 순환 참조로 인한 StackOverflow가 발생하면 애플리케이션이 종료

Description:

The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  memberService defined in file [/Users/mac/test/build/classes/java/main/com/example/user/MemberService.class]
↑     ↓
|  userService defined in file [/Users/mac/test/build/classes/java/main/com/example/user/UserService.class]
└─────┘

생성자 주입을 이용하면 이러한 순환 참조 문제를 방지 가능

생성자 주입 방식을 사용하면 애플리케이션 구동 시점(객체의 생성 시점)에 에러가 발생하기 때문에 서버의 운영 중에 순환 참조로 인한 문제가 생길 가능성이 없음

애플리케이션 구동 시점에 bean 등록을 위해 객체를 생성하는 과정에서 다음과 같이 순환 참조가 발생하기 때문

new UserService(new MemberService(new UserService(new MemberService()...)))

@Autowired를 이용한 필드 주입에서 이러한 문제가 애플리케이션 구동 시점에 에러가 발생하지 않는 이유는 빈의 생성과 조립(@Autowired) 시점이 분리되어 있기 때문

생성자 주입은 객체의 생성과 조립(의존관계 주입)이 동시에 실행되다 보니 위와 같은 에러를 사전에 발견하여 조치 가능

하지만 @Autowired는 모든 객체의 생성이 완료된 후에 조립(의존관계 주입)이 처리

그러다 보니 위와 같이 호출이 되고 나서야 순환 이슈 확인 가능

참고로 스프링부트 2.6부터는 아래와 같이 순환 참조가 기본적으로 허용되지 않도록 변경됨

circuit-refer

Twitter Facebook LinkedIn