객체지향 설계, IoC, DI 컨테이너

이연희·2022년 7월 4일

목록 보기

59/105

객체 지향 설계의 5가지 원칙

SRP 단일 책임 원칙

이전에는 클라이언트 객체가 구현 객체 생성, 연결 실행하는 다양한 책임을 가지고 있었다. SRP 단일 책임 원칙을 준수하기 위해 관심사를 분리하였고, AppConfig가 구현 객체를 생성하고 연결하는 책임을 맡았다. 클라이언트 객체는 실행하는 책임만 담당하게 되었다.

DIP 의존관계 역전 원칙

프로그래머는 구체화가 아닌 추상화에 의존해야 한다. 기존 주문 서비스인 OrderServiceImpl이 DiscountPolicy 인터페이스와 FixDiscountPolicy 구체 클래스에 함께 의존해서 DIP를 위반했다. 클라이언트 코드가 DiscountPolicy 추상화 인터페이스에만 의존하도록 선언만 하고, AppConfig에서 객체 인스턴스를 생성해서 의존관계를 주입하여 DIP 원칙 위반 문제를 해결했다.

OCP 개방-폐쇄 원칙

소프트웨어 요소는 확장에는 열려있고 변경에는 닫혀있어야 하는 원칙이다. 애플리케이션을 사용 영역과 구성 영역으로 나눴기 때문에 클라이언트 코드를 변경하지 않아도 된다. 소프트웨어 요소를 새롭게 확장(할인정책 변경 후 주입)해도 사용영역(클라이언트 코드)의 변경은 닫혀 있는 상태가 된다.

IoC

제어의 역전(IoC: Inversion of Control)

내가 코드를 호출하는 것이 아니라 프레임워크가 내 코드를 호출하는 제어권이 역전된 상태를 말한다. OrderServiceImpl은 필요한 인터페이스를 호출하지만 어떤 구현 객체가 실행될지는 모른다. 예를 들면 MemberRepository에 어떤 Repository 구현 객체가 들어올지 모른다는 뜻이다. 프로그램의 제어 흐름은 AppConfig가 관리하고, OrderServiceImpl은 이 사실을 모른채 자신의 로직만 실행한다. 이렇게 프로그램의 제어를 직접하지 않고 외부에서 관리하는 것을 제어의 역전(IoC: Inversion of Control)이라 한다.

프레임워크 vs 라이브러리

내가 작성한 코드를 제어하고 대신 실행하면 프레임워크이다.(JUnit) 하지만 내가 작성한 코드가 직접 제어의 흐름을 관리하면 이는 라이브러리이다.

DI

의존관계 주입(DI: Dependency Injection)

OrderServiceImpl은 인터페이스들만 의존하기 때문에 실제 어떤 구현 객체가 사용될지는 모른다. 의존관계는 '정적인 클래스 의존관계'와 '실행시점에 결정되는 동적인 객체(인스턴스) 의존 관계'를 분리해서 생각해봐야 한다.

정적인 클래스 의존관계

클래스가 사용하는 import를 보고 의존관계를 쉽게 판단할 수 있다. 애플리케이션을 실행하지 않더라도 분석이 가능하다. 하지만 클래스 의존관계만으로는 실제 어떤 객체가 OrderServiceImpl에 주입될지 알 수 없다.

import hello0703.core.discount.DiscountPolicy;
import hello0703.core.member.Member;
import hello0703.core.member.MemberRepository;

public class OrderServiceImpl implements OrderService {...}

동적인 클래스 의존관계

애플리케이션 실행시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이이언트와 서버에 실제 의존관계가 연결되는 것이다. 클라이언트 코드를 변경하지 않고 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다. 또한 정적인 클래스 의존관계를 변경하지 않고 동적인 객체 인스턴스의 의존관계를 쉽게 변경할 수 있다.