IoC와 DI

IoC와 DI

이전 포스팅에서 좋은 객체지향 설계를 위한 SOLID 원칙을 설명하였다. 그리고 다형성만으로는 OCP와 DIP를 지킬 수 없다는 사실도 확인 하였다. 그렇다면 이 문제를 어떻게 해결할 수 있을까?

영화를 제작한다고 가정해보자. 먼저 배우를 섭외하고 결정해야 하는데 누가 가장 적임자겠는가? 일반적으로 이는 감독의 역할이다. 이제 우리의 프로그램도 연관관계를 맺어주고 결정하는 감독이 필요하다.

IoC (Inversion of Control)

우리의 프로그램도 이제 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요해 졌다. 코드를 통해 살펴보자.

public class MemberService {
    private MemberRepository memberRepository = new JdbcMemberReposititory();
}

위의 코드는 OCP와 DIP를 위배한 코드이다. 영화 제작의 상황이라면 배우가 상대 배역까지 결정하는 경우와 같다.

MemberFactory 등장

public class MemberFactory {
    public MemberRepository memberRepository() {
        return new JdbcMemberReposititory();
    }
}

public class MemberService {
    private MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

public class MemberFactoryTest {
    public static void main(String[] args) {
        MemberFactory memberFactory = new MemberFactory();
        MemberService memberService = new MemberService(memberFactory.memberRepository());
    }
}

MemberFactory를 통해 MemberService는 더 이상 구현체에 의존하지 않게 되었다. 그리고 연관관계를 결정하는 것은 MemberFactory의 역할로 바뀌었다.

이제 MemberRepository를 변경하더라도 클라이언트인 MemberService는 변경하지 않아도 된다. 다시말해 OCP를 지킬 수 있는 것이다.

이제 MemberService의 입장에서 살펴보자. 기존에는 어떤 Repository를 사용할 지 직접 결정 했었다. 그런데 이제는 MemberFactory가 결정하게 되었다. 스스로 어떤 객체를 사용할 지 결정 했었는데 이제 그 권한을 MemberFactory가 가져갔다. 다시 말해 제어권을 가져가 버렸다.(제어권이 역전 되었다)

이를 제어의 역전 (IoC)이라 한다. 코드에서 보았듯 연관관계를 결정하는 제어권을 다른 객체(또는 스프링 컨테이너 같은)에게 위임함으로써 Repository를 변경하는 것에 있어 자유로울 수 있었다. 그리고 이제 MemberService는 구체화에 의존하지 않고 추상화에 의존(DIP)하게 되었다.

DI (Dependency Injection)

위의 코드를 보면 MemberService는 더 이상 구현체에 의존하지 않고(DIP) MemberRepository의 변경(확장)이 발생해도 영향을 받지 않는다.(OCP)

이는 MemberService가 MemberRepository의 의존관계를 외부에서 주입 받기 때문에 가능해졌다. 이렇게 외부에서 의존관계를 주입받는 것을 의존관계 주입(DI)이라 한다.

참고

• 인프런 스프링 핵심원리 - 기본편(김영한)
• 토비의 스프링