이펙티브 코틀린 1장 : 안정성

JooHeon·2022년 7월 1일
0

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 : 결과 부족이 발생할 경우 nullFailure를 사용하라

  • 예외는 발생 후 처리하지 않을 수 있다
  • 예측 가능한 오류는 nullFailure를 사용하고 불가능할 때는 예외를 throw하자
  • try-catch 블록보다 효율적이다
  • nullable을 리턴하지 말고 getOrNull등으로 무엇이 리턴되는지 예측할 수 있게 하자

Item - 8 : 적절하게 null을 처리하라

적절한 대처

  • 당연히 그럴 것이라고 생각하지 못한 부분은 예외를 throw하자

하지 말아야 할 행위

  • not-null assertion(!!) 사용하지 말자
  • 최대한 nullable 을 피하자

Item - 9 : use를 사용하여 리소스를 닫아라

Item - 10 : 단위 테스트를 만들어라

0개의 댓글