Notice
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- rxjava hot observable
- 안드로이드 유닛 테스트
- 클래스
- 멤버변수
- ar vr 차이
- ANR이란
- 안드로이드 라이선스
- 스택 큐 차이
- jvm이란
- 큐 자바 코드
- android retrofit login
- 안드로이드 유닛테스트란
- android ar 개발
- 스택 자바 코드
- 안드로이드 라이선스 종류
- rxjava disposable
- 객체
- rxjava cold observable
- Rxjava Observable
- 자바 다형성
- 2022 플러터 안드로이드 스튜디오
- jvm 작동 원리
- 안드로이드 os 구조
- 안드로이드 유닛 테스트 예시
- 서비스 vs 쓰레드
- 2022 플러터 설치
- 안드로이드 레트로핏 crud
- 안드로이드 레트로핏 사용법
- 서비스 쓰레드 차이
- 플러터 설치 2022
Archives
- Today
- Total
나만을 위한 블로그
[이펙티브 코틀린] 아이템 29. 외부 API를 랩(wrap)해서 사용하라 본문
728x90
반응형
API 설계자가 안전하지 않다고 하거나 API 설계자가 안전하다고 해도 우리가 그걸 신뢰할 수 없다면 그 API는 불안정한 것이다. 이런 불안정한 API를 과도하게 사용하는 것은 굉장히 위험하다. 어쩔 수 없이 이런 API를 써야 한다면 최대한 로직과 직접 결합시키지 않는 게 좋다. 그래서 많은 프로젝트가 잠재적으로 불안정하다고 판단되는 외부 라이브러리 API를 랩해서 사용한다. 랩해서 사용하면 아래와 같은 자유, 안정성을 얻을 수 있다.
- 문제가 있다면 wrapper만 바꾸면 되므로 API 변경에 쉽게 대응 가능하다
- 프로젝트 스타일에 맞춰서 API 형태를 조정할 수 있다
- 특정 라이브러리에서 문제가 발생하면 wrapper를 수정해서 다른 라이브러리를 쓰도록 코드를 쉽게 바꿀 수 있다
- 필요한 경우 쉽게 동작을 추가하거나 수정할 수 있다
단점은 아래와 같다
- wrapper를 따로 정의해야 한다
- 다른 개발자가 프로젝트를 다룰 때 어떤 래퍼들이 있는지 따로 확인해야 한다
- wrapper들은 프로젝트 내부에서만 유효하므로 문제가 생겨도 질문할 수 없다. 스택오버플로우에 질문해도 아무도 답해주지 못할 것이다
장단점을 모두 이해하고 랩할 API를 이해해야 한다. 라이브러리가 얼마나 안정적인지 확인할 수 있는 가장 기본적인 휴리스틱은 버전 번호와 사용자 수다. 일반적으로 라이브러리 사용자가 많을수록 안정적이다.
반응형
'책 > Effective Kotlin' 카테고리의 다른 글
[이펙티브 코틀린] 아이템 31. 문서로 규약을 정의하라 (0) | 2023.01.25 |
---|---|
[이펙티브 코틀린] 아이템 30. 요소의 가시성을 최소화하라 (0) | 2023.01.19 |
[이펙티브 코틀린] 아이템 28. API 안정성을 확인하라 (0) | 2023.01.13 |
[이펙티브 코틀린] 아이템 27. 변화로부터 코드를 보호하려면 추상화를 사용하라 (0) | 2023.01.09 |
[이펙티브 코틀린] 아이템 26. 함수 내부의 추상화 레벨을 통일하라 (0) | 2023.01.09 |
Comments