아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

[Irisation23]

🚨 의존 객체 주입에 앞서 읽어보면 좋은글

의존 객체 주입의 잘못된 예 💥

1. 정적 유틸리티를 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다.

public class SpellChecker {
    private static final Lexicon dictionary = ...;
    
    private SpellChecker() {} // 객체 생성 방지
    
    public static boolean isValid(String word) { ... }
    public static List<Sring> suggestions(String typo) { ... }
}

2. 싱글톤을 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다.

public class SpellChecker {
    private final Lexicon dictionary = ...;
    
    private SpellChecker(...) {}
    public static SpellChecker INSTANCE = new SpellChecker(...);
    
    public boolean isValid(String word) { ... }
    public List<String> suggestions(String typo) { ... }
}

---

그렇다면 궁금증이 생긴다. 대체 왜 테스트하기 어려운 것인가 ⁉️

🧐 유틸리티 클래스가 테스트 하기 어려운 이유는 무엇일까?

• 유틸리티 클래스는 인스턴스 메서드와 인스턴스 변수를 일절 제공하지 않는다.
• 클래스 본래의 목적인 데이터와 데이터 처리를 위한 로직의 캡슐화를 실행하는것이 아니다.
• 단지 유틸리티 클래스의 목적은 비슷한 기능의 메서드와 상수등을 모아서 캡슐화한 것이다.
• 위의 이유를 토대로 테스트 하기 쉽지않음.

• 하지만 그래도 테스트 해보고 싶다면 ⁉️
  • 유용한 테스트 코드 작성 팁의 Static Method Test 부분을 읽어보도록 하자.

🧐 싱글톤 패턴이 테스트 하기 어려운 이유

• 일반적인 싱글톤은 다음과 같이 직접 인스턴스화 된다.

public class MyClass {
    private MySingleton foo = MySingleton.getInstance();
}

• 이 싱글톤의 동작이 시스템 시간을 기반으로 하는 경우 테스트도 시스템 시간에 종속된다.
  • 하지만 그래도 테스트 해보고 싶다면 !?
  • 싱글톤이 해당 유형으로 사용되는 인터페이스를 구현 하는 경우 인터페이스를 전달하는 한 싱글톤을 구현 할 수있다.

public class SomeSingleton implements SomeInterface {
    ...
}

public class MyClass {
    private SomeInterface foo ;

    public MyClass( SomeInterface foo ) {
        this.foo = foo;
    }

    ...
}

...

MyClass m = new MyClass( SomeSingleton.getInstance() ) ;

• 즉 정리하자면 클래스가 작업해야 하는 인터페이스에 의존하는 방법을 선택해야한다.

🚨 뭔가 이상함이 감지 됐다면?? 창과 방패의 관계인 싱글톤 패턴과 유닛테스트 읽어 보는것을 추천!

사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다.

• 위의 SpellChecker가 여러 자원 인스턴스를 지원해야 한다면, 클라이 언트가 원하는 자원(dictionary)을 사용해야 한다.
• 인스턴스를 생성 할 때 생성자에 필요한 자원을 넘겨주는 방식을 채택하는것이 바로 의존 객체 주입이다.

의존 객체 주입의 장점 ✨

import java.util.Objects;

public class SpellChecker {

    private final Lexicon dictionary;

    public SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }
}

• 자원이 몇 개든 의존 관계가 어떻든 상관없다.
• 불변을 보장하여 (같은 자원을 이용하려는) 여러 클라이언트가 의존 객체의 공유가 용이 해지도록 돕는다.
• 의존 객체 주입은 생성자, 정적 팩터리 메서드, 빌더 모두에 응용 할 수있다.
• 해당 의존 객체 주입은 팩터리 메서드 패턴에 이용된다.

---

핵심 정리 📚

• 클래스가 내부적으로 하나 이상의 자원에 의존하고 있고, 그 자원이 클래스 동작에 영향을 준다면
• 싱글톤과 정적 유틸리티 클래스는 사용하지 않는것이 좋다.
• 필요한 자원 (혹은 그 자원을 만들어주는 팩터리를) 생성자에 (혹은 정적 팩터리나 빌더) 넘겨주자.
• 의존 객체 주입 기법은 클래스의 유연성, 재사용성, 테스트 용이성을 개선해준다.

---

출처

• 의존관계 주입(Dependency Injection) 쉽게 이해하기, 3기_완태, 27 APR 2021, https://tecoble.techcourse.co.kr/post/2021-04-27-dependency-injection/
• 유용한 테스트 코드 작성 팁, 지마켓 문한국, 2022. 9. 2. 10:53, https://dev.gmarket.com/38
• 창과방패의 관계인 싱글톤 패턴과 유닛테스트, 김정혁, 2022. 7. 15. 21:57, https://zereight.tistory.com/1222

[jinan159]

아이템 4번을 읽으면서 생겼던 궁금증들이 많이 해소가 되네요👍

유용한 테스트 코드 작성 팁의 Static Method Test 부분을 읽어보도록 하자.
이 글도 잘 읽었습니다.

mockito-inline 이라는게 있는지 처음 알았네요!

[JoisFe]

해당 정리에서 의존 객체 주입을 보면 OOP 5원칙 중 OCP, DIP가 떠올랐습니다.

• OCP : "소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀있다"
  
  처음 이 원칙이 말이 안된다고 생각했었습니다.

public class A {
    private C c = new C();
}


// 변경

public class A {
    private D d = new D();
}

확장을 하려면 코드를 변경해야하는게 아닌가? 했지만 다형성을 이용하여 의존 주입을 이용하면 가능할 수 있다는 것을 알게 되었습니다.

public Class A {
    private I i;

    public A(I i) {
        this.i = i;
    }
}

위 처럼 생성자를 통해 의존 주입을 할 수 있다면 클라이언트 코드에서 만 주입할 코드만 변경해준다면 서버 코드를 수정할 필요가 없게 됩니다. (클래스 A를 서버 코드 라고 하면)

따라서 서버 코드에서는 OCP를 지킬 수 있게 됩니다.
또한 이렇게 변경하는 코드를 주입하게 해주는 것이 다형성이고 이러한 특성을 잘 설명한 것이 DIP인 것 같습니다.

• DIP : "프로그래머는 추상화에 의존해야하고 구체화에 의존해선 안된다."
  

하지만 클라이언트 코드 입장에서 변경은??

public class client {
    private A a = new A(new B());

  // 변경
    private A a = new A(new D());
}

어떻게 보면 이것 또한 OCP를 지키지 못하고 그리고 결국 B, D가 있으니 구현 클래스를 직접 선택하는 즉 DIP를 지키지 못하게 되었습니다.

이 두 원칙을 지키는게 참 힘들다고 느껴졌고 이 부분을 지키기 위해 Spring framework에서는 DI(의존 관계 주입), IOC(제어의 역전) 을 통해 해결한 것으로 알 고 있습니다. 따라서 추후 이부분에 대해서도 같이 알아보면 좋을 것 같습니다.

정리 감사합니다.