[Kotlin / Android] implementation, api

모듈 의존성 주입

처음 안드로이드 개발을 배우면, 어떤 라이브러리를 사용하려 한다면 implementation을 활용해서 의존성을 추가한 기억이 있을 것이다. 개발 문서도 implementation을 사용해서 주입하는 코드가 적혀있고, 단일 모듈로 개발한다면 이러한 방식으로 주입하는 것에 아무런 문제가 없다. 하지만 멀티 모듈을 사용한다면, 또는 그러한 프로젝트를 분석 중이라면, 주입하는 메서드가 implementation 뿐만이 아니라는 것을 알 수 있다.

implementation과 api의 차이

NiA를 뜯어보다가 feature 에서 model 영역을 참조하는 부분이 있다. 하지만, 해당 모듈의 gradle에서 model을 주입하는 부분이 없다. 이 부분을 연구하다가 의존성을 주입하는 방식이 두 가지 있다는 것을 알게 되었다.

implementation

이 메서드로 의존성을 주입하면, 해당 라이브러리는 현재 모듈까지만 전파되고, 상위 모듈에는 캡슐화된다. 즉, A모듈이 B모듈을 implementation으로 받고 있다면, A모듈에서는 B 모듈의 공개 클래스와 함수를 사용할 수 있지만, A를 주입받는 상위 모듈 C에서는 B를 알 수 없다.

api

A모듈이 B모듈을 api로 주입했다면, A 모듈이 B 모듈의 공개 클래스와 메서드에 접근하는 것은 동일하다. 하지만 상위 모듈에서 차이가 발생한다. C가 A를 어떠한 방식으로든 의존성을 주입한다면, C는 B를 알 수 있다. 즉, B의 의존성이 C로 전파된다.

 

gradle이 빌드될 때, 가장 아래 단계의 라이브러리에 대한 주입을 시작하면서 간선을 따라 탐색하는 개념으로 이해했다. api로 주입되었다면 상위 라이브러리로 전파하는 의존성 목록을 만들 때 해당 라이브러리를 추가시키고, implementation으로 주입했다면 포함하지 않는 방식으로 로직이 이루어져 있지 않을까 생각된다. 이러한 탐색 구조 때문에 api를 남용하게 된다면, 단계가 깊어지는 멀티 모듈의 경우 상위 모듈로 전파해야 하고 의존성을 주입하는 과정에서 불필요한 비용이 많이 발생하게 될 것이므로 남용 시 빌드 속도가 느려지는 이유를 설명할 수 있을 것 같다.

멀티 모듈

이 점을 활용하면 멀티 모듈의 설계도 쉬워질 것으로 보인다. 모듈 간의 의존성 관계를 도식화하여 정의한 후, 그 규칙에 맞게 라이브러리를 주입할 수 있으므로 문서화에도 굉장히 유리할 것으로 보인다.