🖥순수 JAVA 코드를 통해 알아보는 스프링 핵심 IOC(제어의 역전), DI(의존관계 주입)❗️🧑🏻‍💻

스프링의 핵심을 알기 위해선 객체지향 5원칙(SOLID)에 대해 먼저 알고 있어야 한다.

하나의 예시를 통해 알아보자. 회원을 가입하고 회원을 조회하는 예제이다.

1. 왼쪽은 회원의 등급을 나타내는 클래스 (상수들끼리 모아 놓은 enum(열거형)이고 오른쪽은 회원 클래스이다.

2. 왼쪽은 회원을 저장할 경우에 그냥 메모리에 저장할 수 있고, 자체 디비나, 외부 디비에 저장할 수 있으므로 회원저장소를 인터페이스로 추상화 했고, 오른쪽은 회원저장소 인터페이스를 구체화한 메모리에 회원의 정보를 저장하는 구현클래스이다.

3. 왼쪽은 회원서비스에 대한 인터페이스이고 오른쪽은 회원 서비스를 구체화한 구현클래스이다.

3번 오른쪽 이미지에서 다음 코드를 볼 수 있다.

private final MemberRepository memberRepository = new MemoryMemberRepository();

이 코드에 MemberServiceImpl 이라는 구현 클래스는 MemberRepository 인터페이스뿐 아니라 MemoryMemberRepositroy 라는 구체 클래스에도 의존을 하고 있다.

즉 객체지향 5원칙 OCP (개방 폐쇄 원칙)과 DIP(의존 관계 역전 원칙)을 위반하고 있는 셈이다. 그 이유는 OCP는 변경에는 닫혀있으나 확장에는 열려있어야 하는 것인데 여기서 클라이언트는 MemberServiceImpl 클래스이다.

지금은 MemoryMemberRepository(메모리)를 사용하고 있지만 만약 DBRepository(디비)를 사용하여 회원 정보를 저장한다면

private final MemberRepository memberRepository = new DBRepository();

이렇게 코드가 바뀔 것이고 클라이언트 코드(MemberServiceImpl class)가 영향을 받는다.

그래서 이는 OCP를 위반하는 것이고, 클라이언트 코드는 추상화(인터페이스)에만 의존해야 하지만 보았듯이 구체 클래스에도 의존하고 있기에 DIP까지 위반하고 있는 셈이다.

추가적으로 클라이언트가 하나의 책임 즉 실행에만 신경을 써야하는데, 무엇을 자신이 메모리에 저장할지 디비에 저장할지 등을 결정하고 있는 셈이다. SRP(단일책임 원칙)까지 위배하고 있는 셈이다.

다음으로는 위 문제점을 해결하는 방법이다. 위 문제를 해결하기 위해서는 인터페이스에만 의존해야 한다‼️ 인터페이스에만 의존하게 하고 어디에 저장을 할지는 외부에서 주입을 받으면 될것이다.

밑에 다이어그램을 보게 되면 OCP와 DIP 모두를 지킨 다이어그램이다.

위 다이어그램과 같이 애플리케이션의 전체 동작 방식을 구성 하기 위해 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스를 만들었다

AppConfig 클래스에서 실제 동작에 필요한 구현 객체를 생성하고, 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다.

오른쪽 MemberServiceImpl에서 코드가 수정된것을 볼 수 있다.

Private final MemberRepository memberRepository;

이 코드를 보면 드디어 인터페이스에만 의존을 하게 되었고 그 다음 코드를 보면 생성자를 만들어서 어떤 것으로 저장할지는 AppConfig클래스(외부)에서 결정을 하게 된다.

이렇게 해서 MemberServiceImpl클래스에서는 생성자를 통해 어떤 구현 객체가 들어올지 모르게 되고, 의존관계는 외부에 맡기고 저장, 조회 등 기능을 실행하는 데에만 초점을 맞출 수 있게 된다.

클라이언트인 MemberServiceImpl클래스 입장에서 봤을 때 의존 관계를 외부에서 주입해주는 것 같아 이것을 👍🏻 DI(Dependency Injection) 의존성 주입 다른 말로 의존관계 주입이라고 한다.

AppConfig 클래스에서 중복을 제거하고 역할에 따른 구현이 보이도록 리팩토링을 하면 다음과 같이 나온다.

리팩토링을 했을 때의 장점은 애플리케이션의 전체 구성이 어떻게 되어있는지 한눈에 볼 수 있다는 점이다.

지금까지를 정리해보면 MemberServiceImpl이라는 클래스가 자신의 기능 뿐 아니라 어디에 저장할지 까지 결정을 하여 OCP, DIP를 위반했다.

그러나 AppConfig라는 클래스를 만들어 외부에서 어디에 저장할지 객체를 주입해 줌으로써 프로그램에 대한 제어흐름이 AppConfig클래스로 넘어갔다.

이를 IOC(제어의 역전)이라 하고, 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 DI(의존관계 주입)이라 한다!! 🖥

출처

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard