[DI] 왜 생성자 주입은 순환 의존성을 피하는 데 도움이 되는가

출처

ChatGPT

Gemini

---

순환 의존성 Circular Dependency

두 개 이상의 클래스나 모듈이 서로를 직접 또는 간접적으로 의존할 때 발생하는 문제. 마치 뱀이 자신의 꼬리를 물고 있는 모습과 같다고 생각하면 이해하기 쉽니다.

 

순환 의존성의 문제점

1. 유지보수 어려움

클래스 간의 의존성이 복잡하게 얽혀 있어 코드의 변경이나 확장이 어려워질 수 있다.한 클래스를 수정하면 연쇄적으로 다른 클래스에도 영향을 미쳐 코드 변경이 복잡해지고 오류 발생 가능성이 높아진다.

2. 테스트의 어려움

개별 클래스를 독립적으로 테스트하기 어려워지고, 시스템 전체를 테스트해야 하는 부담이 커진다.

3. 코드 이해도 저하

코드의 흐름을 파악하기 어려워져 유지보수 인력이 코드를 이해하는 데 많은 시간이 소요된다.

4. 결합도 증가

클래스 간의 결합도가 높아져 시스템의 유연성이 떨어지고 재사용성이 낮아진다.

 

순환 의존성이 발생하는 이유

1. 잘못된 설계

시스템 설계 초기 단계에서 클래스 간의 관계를 명확하게 정의하지 않아 발생할 수 있다.

2. 중복된 기능

두 개 이상의 클래스에서 동일한 기능을 수행하는 코드가 존재할 때 발생할 수 있다.

3. 과도한 의존성

한 클래스가 너무 많은 클래스에 의존할 때 발생할 수 있다.

 

순환 의존성을 해결하는 방법

1. 리팩토링 / 디자인 개선

코드를 재구성하여 클래스 간의 의존성을 줄이고 모듈화를 높인다.

클래스의 책임을 분리하고, 의존성을 줄이는 방식으로 설계를 개선한다. SOLID 원칙 중 단일 책임 원칙(SRP)와 인터페이스 분리 원칙(ISP)을 적용해 클래스를 더 작고 응집력 있게 만든다.

2. 중간자 패턴 Mediator Pattern

클래스 간의 직접적인 의존성을 제거하고, 중간자 역할을 하는 객체를 도입하여 클래스 간의 상호작용을 관리한다. 객체 간의 의존성을 간접적으로 관리하여 순환 의존성을 피할 수 있다.

 

예

class Mediator(val classA: ClassA, val classB: ClassB) {
    fun doSomething() {
        classA.doA()
        classB.doB()
    }
}

 

3. 의존성 역전 원칙 Dependency Inversion Principle

고수준 모듈이 저수준 모듈에 의존하지 않도록 추상화 계층(인터페이스)을 도입한다.

4. 모듈화

시스템을 작은 모듈로 나누고, 각 모듈 간의 의존성을 최소화한다.

 

생성자 주입이 순환 의존성을 피하는 방법

1. 컴파일 타임 오류

생성자 주입을 사용하며, 순환 의존성이 있을 때 컴파일 타임에 오류가 발생한다. 이는 문제를 조기에 발견하고 수정할 수 있게 해준다. 

 

예

class ClassA(val classB: ClassB)

class ClassB(val classA: ClassA)

 

위의 코드에서 'ClassA'와 'ClassB'는 서로 생성자에서 주입받기 때문에, 순환 의존성으로 인해 컴파일 오류가 발생한다.

 

2. 설계 개선 유도

생성자 주입은 객체 설계를 개선하도록 유도한다. 순환 의존성을 피하기 위해 클래스 간의 결합도를 낮추고, 인터페이스를 활용해 설계를 개선할 수 있다.

3. 의존성 주입 순서 결정

생성자 주입은 의존성 주입 순서를 명확하게 정의한다. 모든 의존성은 객체 생성 시에 제공되어야 하기에, 순환 의존성이 존재할 경우 DI 컨테이너는 이를 해결할 수 없다. 이는 개발자가 의존성 주입 순서를 명확히 이해하고 관리하도록 돕는다.

 

결론

생성자 주입은 객체 설계를 단순하고 명확하게 해 순환 의존성을 피하는 데 효과적이다. 이는 시스템의 유지보수성과 안전성을 높익고, 컴파일 타임에 문제를 발견할 수 있게 해 개발 과정을 개선한다.