📝 기록하게 된 배경
implementation "org.jetbrains.kotlinx:kotlinx-serialization-json:1.4.1"
api 'com.squareup.retrofit2:converter-gson:2.1.0'
compile 'com.squareup.okhttp3:logging-interceptor:3.4.1'네트워크 모듈 설계 중 retrofit을 적용하기 위해 build.gradle 파일에서 dependencies 블록에 라이브러리 종속성을 선언하였습니다.
선언 방식에는 api와 implementation이 있는데, 둘 중에서 implementation을 사용하는 이유가 궁금해졌습니다.
(+ 찾아보니 compile 방식도 있어 같이 알아보고자 합니다.)
Gradle은 api나 compile 사용을 권장하지 않습니다.
api를 통해 라이브러리를 가져올 경우 라이브러리가 적용되는 범위 때문입니다.
(compile은 deprecated 되었습니다.)
api, compile의 라이브러리 적용 범위
모듈에서 api나 compile을 사용해 라이브러리를 가져오게 되면, 해당 라이브러리는 해당 모듈을 의존하는 다른 모듈에서도 접근 가능하다.
Ex) Module A에서 api를 사용해 Library를 가져온 다음 Module B에서 api를 사용해 Module A를 가져올 경우 Module A가 가지고 있던 Library를 같이 접근할 수 있게 됩니다. 그럼 Module C는 모든 라이브러리를 접근할 수 있게 됩니다.
즉, Library a가 수정이 된다면 이를 의존하고 있는 관계인 Module B와 Module C 모두 rebuild가 발생됩니다.
문제점
- 속도 면에서 소요시간이 길어지는 문제
- 연결된 모든 모듈의 api가 노출
이는 프로그램 유지보수성 측면에서 매우 치명적이기에 Multi-Module을 적용한 의미가 사라진다.
implementation의 라이브러리 적용 범위
모듈에서 implementation을 사용해 가져오는 라이브러리는 해당 모듈을 의존하는 모듈에 가져와지지 않는다.
Ex) Library a를 수정하게 되면 Library b만 rebuild가 됩니다. 즉, implementation은 직접적으로 의존 관계에 있는 Library b만 업데이트 되는 방식입니다.
implementation은 연결 의존을 직접적인 관계에만 집중하니, dependency가 compile(api)에 비해 더 가볍습니다. 그리고 수정이 일어났을 때도 직접 의존하고 있는 모듈만 업데이트하니 소요 시간도 훨씬 적습니다. 추가적으로 C에서는 A에 직접 접근할 수 없습니다.
장점
- 직접 의존하고 있는 모듈만 업데이트 해서 소요시간이 훨씬 적다
- dependency가 api,compile에 비해 더 가볍다
정리
api를 이용하면 위 그림에서 Library c는 Library A와 Library B의 인터페이스를 모두 노출시킵니다.
즉, Library A에서 정의된 클래스 타입을 리턴할 수도 있습니다.
반대로 implementation을 이용하면 Library A는 Library C의 내부적으로만 사용됩니다.
(내부 메서드로만, 직접적인 클래스 타입 참조 불가)
프로그래밍 유지보수의 핵심은 모듈간 의존성을 줄이는 것이다.
결론. api 쓰지말고 implementation 씁시다!
Reference
https://blog.naver.com/PostView.nhn?blogId=adamdoha&logNo=222074878978