DI 적용도 생각하는 힘과 함께 하자
도메인 스토리텔링 응용 14
<Loosely-coupled 그리고 스프링 프레임워크>편에서 dependency injection을 소환해 글을 쓰고 나서 지인의 페북에서 DI를 다루는 글이 (떡밥처럼) 올라왔다. 그래서 (냉큼 물고) 글을 쓴다. :)
DI가 유지보수성을 올려준다?
지인이 함께 인용한 트위터 대화가 배경이 되기 때문에 올려본다.
개인적으로는 아래 표현 자체가 굉장히 성급한 일반화로 보인다.
DI가 코드 유지보수성을 크게 올려주는...
이는 마치 보수 정권이 들어서면 안보가 강화된다거나 경제가 성장한다는 믿음과 비슷하게 느껴진다.
DI는 무엇인가? 다시 생각해보자
기존에 썼던 글을 소환한다. 이제는 절대 다수 개발자의 도구라고 할 수 있는 스프링 프레임워크 등장 초기에 Dependency Injection 패턴이 유행했다. 2004년에 마틴 파울러가 쓴 글 Inversion of Control Containers and the Dependency Injection pattern을 찾을 수 있다. 지금은 패턴을 배우기 보다 스프링을 배우며 자기도 모르게 익히는 방법이다.
당시 널리 쓰이던 UML 표기(클래스도)다. UML에서 관계를 표현하는 선 중에 실선은 연관(association)이라고 한다. 그런데 위키피디아 Loosely-coupled 정의에서 본 약한 연관(weakly associated)은 어떻게 표현할 수 있을까? 점선으로 표현할 수 있다. 점섬은 UML에서 의존(dependency) 혹은 의존관계라고 한다. 자연어 정의는 엄밀하기 어렵다. 그래서, 그 차이를 프로그램 적으로 설명해보면, 바로 dependency injection에 대한 설명이 된다.
언제 DI가 필요할까?
말 그대로 연관관계를 이루는 객체가 바뀔 수 있을 때 써야 한다. UML 표기법중에 연관 혹은 의존[1]을 유형 구분 중에 Composition과 Aggreagation이 있다.
UML Aggregation실선으로 표시하는 연관(association)의 한쪽 끝이 마름모이고 그 속이 비어있다면 Aggregation 관계라고 한다. 구글링으로 찾은 설명을 보면, Compsition에서 마름모가 없는 쪽은 혼자서 존재할 수 없는 관계다.
In contrast to a composition, a part of a whole can exist without the whole.
이와 달리 마름모 안을 채우면 Composition 이라고 한다.
UML CompositionDI는 적절한 조직을 만들기 위한 패턴이다
이쯤에서 이 글의 동기를 제공한 안티패턴을 다시 소환하자.
UML 용어를 사용해 표현을 바꿔보면, Aggreagation이 필요한 곳에 써야 한다. 다시 말해 주입 대상 개체(객체)가 별도의 생성 과정을 필요로 하던가 여러 개체에서 동시에 사용할 때 말이다. 그렇지 않은 경우는 Composition 관계를 갖거나 그냥 개체 내부에서 처리하는 편이 좋다.
처음 C 프로그래밍을 배울 때, 중괄호({, }) 로 구분하는 영역 어디에 위치하느냐에 따라 변수의 생명이 유지되는 규칙이 매우 중요했다. Principle of least privilege로 기억하는데, 객체지향(Object Orientated) 패러다임을 배우기 전까지 아마도 가장 자주 떠올리고 써먹은 원칙이 아닐까 싶다.
[1] 엄격하게 UML 문법을 따지며 연관과 의존은 다르지만 DI 적용관점으로 국한하면 연관과 의존의 구분은 무의미하다.
지난 도메인 스토리텔링 응용
6. 도메인 모델, Ongoing 설계 그리고 정원관리
7. 입장에 맞춰 맥락을 나눈 BoundedContext
11. Loosely-coupled 그리고 스프링 프레임워크
