Spring Framework - 의존관계 자동 주입 - 2. 생성자 주입의 장점과 lombok

들어가며

• 이전 포스트에서 스프링 프레임워크가 의존관계 자동 주입을 하는것과 자동 주입 방식에 대해 알아보았다.
• 사실 이전에 배운 3가지의 DI 방식 중 어떤 방식을 사용해야 하는가에 대해서는 이미 정해진 방식이 존재한다. 바로 생성자 주입(Constructor Injection) 방식인데 이번 포스트에서는 왜 생성자 주입을 사용해야 하는가에 대한 이유와 lombok을 통한 코드 간소화 방법에 대해서도 알아본다.

Spring Framework - 의존관계 자동 주입 - 의존관계 주입 방법

 

 

 

생성자 주입을 선택하는 이유

불변성

• 생성자 주입 코드는 다음과 같다.

@Component
public class OrderServiceImpl implements OrderService{
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    @Autowired
    OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy){
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
    
    ...
}

• 이전 포스팅에서도 설명했었지만 기본적으로 생성자 주입은 final 키워드를 통해 불변성을 보장받을 수 있다.
• 또한 스프링 컨테이너에서 해당 객체를 빈으로 등록하는 그 시점에만 단 한 번 동작하므로 이를 통해서도 불변한다는 성질을 보장받을 수 있다.
• 이러한 불변성은 설계 관점에서 강력한 이점이 되는데, 일반적으로 사용되는 의존관계 주입은 한 번 주입이 발생하면 그 이후에 애플리케이션 종료까지 그 관계가 변경할 일이 없다.
  • 사실상 몇 가지 특수한 케이스를 제외하면 애플리케이션 종료까지 주입받은 의존관계가 변경이 발생해서는 안된다.
• 이러한 사실을 인지한 상태에서 수정자 주입을 생각해보자.

@Component
public class OrderServiceImpl implements OrderService{
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
    
    @Autowired
    public void setMemberRepository(MemberRepository memberRepository){
        this.memberRepository = memberRepository;
    }
    
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy){
        this.discountPolicy = discountPolicy;
    }
    
    ...
}

• 수정자 주입 방식을 사용하기 위해서는 결국 Setter를 public하게 열어두어야 한다. 문제는 의존관계를 주입받고 난 후에 Setter는 사실상 필요하지 않은 메서드가 된다는 점이다.
• 심지어 public하게 열어둔 탓에 외부에서 자칫 잘못하면 접근하는 일이 발생할 수 있고, 최악의 경우에 public하게 열어둔 Setter로 인하여 불변성이 깨질 수도 있다. 변경되면 안되는 상태를 변경시키는 메서드를 외부에 대해 열어 놓는 설계는 좋은 설계가 아니다.

 

누락과 프레임워크 의존성

• 다음과 같은 Setter Injection코드를 보자.

@Component
public class OrderServiceImpl implements OrderService{
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
    
    @Autowired
    public void setMemberRepository(MemberRepository memberRepository){
        this.memberRepository = memberRepository;
    }
    
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy){
        this.discountPolicy = discountPolicy;
    }
    
    ...
}

• 해당 구현체를 사용하는 테스트를 스프링 프레임워크에 의존하지 않는 순수 자바 코드로 테스트하고 싶을 때는 어떻게 해야할까?
• @Autowired는 주입받아야 할 의존 관계를 주입받지 못하면 오류가 발생하지만, 해당 어노테이션은 어디까지나 스프링 프레임워크 내부에서 동작할 때만 온전히 동작한다. 즉, 스프링 프레임워크에 의존적인 방식이다.
• 따라서 순수 자바 코드로 테스트를 짠다면 문제가 발생할 수 있다.

public class OrderServiceTest{
    @Test
    void createOrder(){
        OrderServiceImpl orderServiceImpl = new OrderServiceImpl();
        orderService.createOrder(1L, "itemA", 10000);
    }
}

• 위와 같은 테스트는 실행은 가능하다. 하지만 런타임 도중에 NullPointerException이 발생한다.
• 이는 의존관계를 주입받아야 하는 memberRepository와 discountPolicy가 제대로 주입받지 못하기 때문이다. 스프링 프레임워크에 독립적인 테스트이기 때문에 @Autowired가 동작하지 않는 것이다.
• 생성자 주입을 사용할 경우에 주입 데이터를 누락할 때 컴파일 오류가 발생하며 IDE에서 어떤 값을 필수로 주입해야 하는지에 대해 설명한다.
  
  • 이는 위 테스트에서 생성자를 호출할 때 필수로 들어가야 하는 값들이 넘어오지 않고 있기 때문에 컴파일 수준에서 곧바로 에러가 발생하는 것이다.

@Component
public class OrderServiceImpl implements OrderService{
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    @Autowired
    OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy){
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
    
    ...
}

• 또한 생성자 주입의 경우 다른 주입과는 다르게 final를 붙일 수 있는데 final의 경우 생성자가 호출되는 등의 여러 동작으로 단 한 번 초기화 되고 그 이후에 변경되는게 불가능하다.
• 따라서 생성자에서 초기화되지 않는다면 컴파일 에러가 발생한다. 이는 만약 실수로 생성자를 구현할 때 필수 파라미터를 누락하는 경우, 컴파일 수준에서 해당 누락을 잡아주기 때문에 안전한 작업이 가능하다는 장점도 존재한다.

 

 

 

Lombok을 사용한 코드최적화

• 생성자 주입이 안전하고 가장 좋은 주입이란 것은 위에서 알아보았다.
• 문제는 생성자 주입의 경우 어떻게던 생성자 주입을 사용해야 하기 때문에, 생성자의 구현이 필요하다. 이는 곧 개발자가 타이핑을 해야하는 코드가 많아진다는 의미이기도 하다.
• 이는 우리 개발자들에게 전혀 좋지 않은 일이기도 하다. 괜히 필드 주입이 코드량이 적어서 선호받던게 아니다.
• 이럴 때 사용되는 라이브러리가 Lombok이다. Lombok은 여러 어노테이션을 통해 프로그래머가 자주 타이핑해야 하는 보일러플레이트 코드들을 획기적으로 줄여준다.
  • 보일러플레이트(Boilerplate Code)는 어떤 특정 코드의 Form이 여러 지점에서 동일하게 나타는것을 일컫는다.
  • 가장 대표적인 것으로는 class 정의 시에 Getter와 Setter를 생각해볼 수 있다.

public class Person{
    private String name;
    private int age;
    
    public String getName(){
        return name;
    }
    
    public int getAge(){
        return age;
    }
    
    public void setName(String name){
        this.name = name;
    }
    
    public void setAge(int age){
        this.age = age;
    }
}

• 이러한 코드를 줄이기 위해서 Lombok을 활용할 수 있다. Lombok은 @Getter와 @Setter 어노테이션을 통해 Getter, Setter를 자동으로 코드에 집어넣는 기능을 제공한다.

@Getter
@Setter
public class Person{
    private String name;
    private int age;
}

• 정말 드라마틱하게 코드가 줄어든 것을 확인할 수 있다.
• Lombok은 생성자도 어노테이션을 지정함으로서 컴파일 시에 코드가 들어가도록 할 수 있는데 생성자 관련된 어노테이션은 대표적으로 다음과 같은 것들이 있다.
  • @AllArgsConstructor
  • @NoArgsConstructor
  • @RequiredArgsConstructor
• @AllArgsConstructor는 클래스에 존재하는 모든 필드를 사용하는 생성자 코드를 생성한다.
• @NoArgsConstructor는 어떠한 파라미터도 없는 생성자 코드를 생성한다.
• @RequredConstructor는 필수적인 필드들만 파라미터로 두는 생성자 코드를 생성한다. 이때 필수적인 필드들은 생성자가 호출될 때 단 한번 초기화 될 수 있는 final 키워드가 붙은 필드들이다.
• 생성자 주입에서 필수적으로 의존 관계를 주입받아야 하는 필드들은 final을 붙일 수 있다고 했으므로 @RequiredConstructor를 통해 깔끔하게 만들어볼 수 있어 보인다.

@Component
@RequiredConstructor
public class OrderServiceImpl implements OrderService{
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    ...
}

• @Autowired는 생성자가 하나만 존재할 경우에 생략이 가능하다고 했으므로 생성자를 아예 제거하고도 Lombok에 의해 동일하게 기능하는 서비스 구현체를 만들 수 있다.
• 앞으로의 포스팅에서 Lombok이 사용되는 경우에 해당 어노테이션에 대해 설명도 부가적으로 수행할 예정이다.

 

 

정리

• 의존관계 주입 방식은 가급적 생성자 주입을 사용하자. 여러가지 강력한 이점을 얻어갈 수 있다.
• Lombok을 통해 많은 보일러플레이트 코드를 줄여 최적화가 가능하다.
• 다음 포스트에서는 @Autowired를 통해 자동으로 주입받는 도중 여러 개의 빈이 충돌하는 경우에 어떻게 처리해야 하는지에 대해 알아본다.