Item - 1 : 가변성을 제한하라
가변성의 문제 (var
)
- 프로퍼티가 변경가능 상태면 변경내역에도 의존하게 된다
- 동시성 문제에서 자유롭지 못하다
- 테스트하기 어렵다
적절한 대처
- 읽기 전용 프로퍼티(val) 사용
immutable
, mutable
객체를 구분해서 사용
immutable
객체의 프로퍼티는 적절한 내부 메서드를 통해 변경
data
한정자의 copy
메서드를 활용하는 걸 추천
- 변경가능 지점을 노출하지 않기
mutable
객체를 그냥 반환하지 말고 복제해서 반환하기 (방어적 복제)
- 가변성을 제한하기 (
immutable
객체)
하지 말아야 할 행위
- 컬렉션 다운캐스팅 (ex.
list
-> mutableList
)
결론
가능한 가변성을 제한한 immutable
객체, 프로퍼티, 컬렉션 등을 사용하고 mutable
객체를 외부에 노출하지 말자
Item - 2 : 변수의 스코프를 최소화하라
장점
- 프로그램을 추적하고 관리하기 쉽다
- 코드를 분석할 때 어떤 시점에 어떤 요소가 있는지 알기 쉽다
- 어플리케이션이 간단할수록 읽기도 쉽고 안전하다
적절한 대처
- 변수를 정의할 때 초기화하자
- 여러 프로퍼티를 한꺼번에 설정해야 하는 경우에는 구조분해 선언을 활용하자
스코프가 클 때 잠재적인 위험
Item - 3 : 최대한 플랫폼 타입을 사용하지 말라
플랫폼 타입 : 다른 프로그래밍 언어에서 전달되어 nullable
인지 알 수 없는 타입
-> 코틀린에선 자바에서 넘어온 것을 의미하며 !
기호를 붙여서 표기함
적절한 대처
- 자바와 코틀린을 같이 사용할 땐 자바 코드에
@Notnull
또는 @Nullable
을 붙여 명시하자
- 플랫폼 타입은 안전하지 않으므로 빨리 제거하자
-> null
인지 아닌지 모르는 상태에서 플랫폼 타입은 활용 시점에 오류가 발생하기 때문에
플랫폼 타입이 다른 곳에서 사용되는 일은 굉장히 위험하다.
Item - 4 : inferred 타입으로 리턴하지 말라
- 외부에서 수정하기가 매우 힘들다.
- 외부에서 확인할 수 있게 명시적으로 지정해주는 것이 좋다.
Item - 5 : 예외를 활용해 코드에 제한을 걸어라
장점
- 제한을 걸면 문서를 읽지 않은 개발자도 문제를 확인할 수 있다
- 문제가 있을 경우에 함수가 예상하지 못한 동작을 하지 않고 예외를 던진다
- 상태를 관리하기가 쉬워지고 코드가 더 안정적으로 작동한다
- 코드가 어느 정도 자체적으로 검사되기 때문에 단퀴 테스트를 줄일 수 있다
- 스마트 캐스트 기능을 활용할 수 있게 되므로 캐스트를 적게 할 수 있다
require()
- 개발자가 바라는 형태의 파라미터 형식으로 받기 위해
require()
가 있다
- 조건에 부합하지 않으면
IllegalArgumentException
을 던진다
check()
check()
는 require()
와 유사한 사용법으로 상태가 올바른지 체크한다
- 조건에 부합하지 않으면
IllegalStateException
을 던진다
- 사용하면 안 되는 곳에서 함수를 호출하고 있다고 의심될 때 사용한다
assert()
- 올바르게 구현 됐을 때 참인지 확인할 때 사용
Item - 6 : 사용자 정의 오류보다는 표준 오류를 사용하라
Item - 7 : 결과 부족이 발생할 경우 null
과 Failure
를 사용하라
- 예외는 발생 후 처리하지 않을 수 있다
- 예측 가능한 오류는
null
과 Failure
를 사용하고 불가능할 때는 예외를 throw
하자
- try-catch 블록보다 효율적이다
- nullable을 리턴하지 말고
getOrNull
등으로 무엇이 리턴되는지 예측할 수 있게 하자
Item - 8 : 적절하게 null을 처리하라
적절한 대처
- 당연히 그럴 것이라고 생각하지 못한 부분은 예외를
throw
하자
하지 말아야 할 행위
not-null assertion(!!)
사용하지 말자
- 최대한
nullable
을 피하자
Item - 9 : use를 사용하여 리소스를 닫아라
Item - 10 : 단위 테스트를 만들어라