녹화된 배경
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'네트워크 모듈 설계 중에 개조를 적용하기 위해 라이브러리 종속성은 build.gradle 파일의 종속성 블록에서 선언됩니다.
선언 방식에서 API그리고 구현두 가지 구현을 사용하는 이유가 궁금했습니다.
(+ 찾아보니 Compile 방식도 있어서 같이 알아보고자 합니다.
)
Gradle은 API 사용 또는 컴파일을 권장하지 않습니다.
API를 통해 라이브러리를 가져올 때 라이브러리의 범위 때문에.
(컴파일은 더 이상 사용되지 않습니다.
)
API의 라이브러리 커버, 컴파일
모듈이 API 또는 컴파일러를 사용하여 라이브러리를 가져오면 모듈에 종속된 다른 모듈에서 라이브러리에 액세스할 수 있습니다.
예: 모듈 A에서 API를 사용하여 라이브러리를 가져온 다음 모듈 B에서 API를 사용하여 모듈 A를 가져오면 모듈 A가 가지고 있던 라이브러리에 동시에 액세스할 수 있습니다.
그런 다음 모듈 C는 모든 라이브러리에 액세스할 수 있습니다.
즉, 라이브러리 A가 변경되면 모듈 B와 모듈 C가 이에 종속됩니다.
모든 수정이 완료되었습니다것이 가능하다.
문제
- 속도 측면에서 리드타임이 긴 문제
- 연결된 모든 모듈의 API 제공
이는 프로그램 유지보수 측면에서 매우 치명적이므로 다중 모듈 사용의 중요성이 사라집니다.
구현 라이브러리 범위
모듈의 구현을 사용하여 가져온 라이브러리는 해당 모듈에 종속된 모듈로 가져오지 않습니다.
예) 라이브러리 a가 변경된 경우 라이브러리 b를 다시 빌드하십시오.된다.
즉 구현 직접적인 의존성이렇게 하면 라이브러리의 b만 업데이트됩니다.
시행은 연도직접적인 관계에만 집중하고, 종속성은 컴파일하는 것보다 쉽습니다(api).. 그리고 변경 사항이 발생하면 이에 직접적으로 의존하는 모듈만 업데이트됩니다.
시간이 훨씬 덜 걸립니다. 또한 C에서 직접 A에 액세스할 수 없습니다.
장점
- 직접 의존하는 모듈만 업데이트되므로 시간이 훨씬 적게 걸립니다.
- 종속성은 api 및 컴파일보다 가볍습니다.
정리하다
API를 사용하여 라이브러리는 위 그림에서 c입니다.
라이브러리 A와 라이브러리 B의 인터페이스를 노출합니다.
즉, 라이브러리 A에 정의된 클래스 유형을 반환할 수도 있습니다.
구현과 반대로 라이브러리 A는 라이브러리 C에서만 내부적으로 사용됩니다.
(내부 메서드 전용, 직접적인 클래스 유형 참조 없음)
프로그래밍 유지 관리의 핵심은 모듈 간의 종속성을 줄이는 것입니다.