바닥부터 천천히

스터디/이펙티브코틀린

아이템 12 - 연산자 오버로드를 할 때는 의미에 맞게 사용하라

연산자 오버로딩은 그 이름의 의미에 맞게 사용하자. 큰 힘에는 큰 책임이 따른다. 코틀린에서 ! 연산자는 boolean의 반대를 나타내는 not 연산을 의미한다. 이런 연산자를 팩토리얼을 표현하기 위해 아래와 같이 표현한다면 다음과 같다. 10 * !6 그리고 위 코드를 not으로 읽어보면 아래와 같이 된다. 10 *6.not() 오버로딩을 이런식으로 활용하면 혼란스럽고 오해의 소지가 있다. 코틀린의 모든 연산자는 별칭이다. 즉, 본래의 이름이 있기 때문에 그 의미를 벗어나도록 오버로딩하면 안된다. 분명하지 않은 경우 그런데 오버로딩을 한 연산자가 이름의 뜻을 제대로 의미하는지(관례를 충족하는지) 확신이 들지 않을 때가 있다. 아래의 경우 * 는 함수를 여러번 실행시키는 의미로 사용되었다. 3 * pri..

스터디/이펙티브코틀린

아이템 11 - 가독성을 목표로 설계하라

프로그래밍은 쓰기보다 읽기가 중요하다 고로 항상 가독성을 생각하면서 코드를 작성해야 한다. 그렇지 않으면 오류를 찾기위해 코드를 작성할 때보다 오랜 시간 코드를 읽는 자신을 발견할 수 있다. 개발자가 코드를 작성하는 데는 1분 걸리지만, 이를 읽는 데는 10분이 걸린다. by 로버트 마틴 인식 부하 감소 가독성이란 코드를 읽고 얼마나 빠르게 이해할 수 있는지를 의미한다. 경험과 인식에 대한 과학으로 만들어진 어느 정도의 규칙이 있다. fun readGood(person: Person?, view: View) { if (person != null && person.isAdult) { view.showPersion(person) } else { view.showError() } } fun readBad(pe..

스터디/이펙티브코틀린

아이템 10 - 단위 테스트를 만들어라

코드를 안전하게 만드는 방법은 다양한 종류의 테스트를 하는 것이다. 대부분의 관리자에게 테스트는 사용자 관점에서 애플리케이션 외부적으로 제대로 작동하는지 확인하는 것이 목표이다. 물론 개발자에게도 유용하지만 충분하지 않다. 개발자는 각 요소가 올바르게 작동한다는 것을 보증하고 빠른 피드백을 받으며 개발하기 위해 단위 테스트가 필요하다. 테스트 내용 단위 테스트는 일반적으로 아래 내용을 확인함으로써 개발자가 만들고 있는 요소가 제대로 동작하는지를 빠르게 피드백해줄 수 있어 도움이 된다. 일반적인 유스 케이스: 예상되는 일반적인 방법 일반적인 오류 케이스, 잠재적인 문제: 동작하지 않을 거라고 예상되는 일반적인 부분, 과거에 문제가 발생한 부분 Edge 케이스, 잘못된 매개변수의 입력 테스트 장점 테스트로 ..

스터디/이펙티브코틀린

아이템 9 - use를 사용하여 리소스를 닫아라

use 메서드를 사용하면 Closeable/ AutoCloseable 를 구현한 객체를 쉽고 안전하게 처리할 수 있다. 더 이상 필요하지 않을때, close 메서드를 사용해서 명시적으로 닫아야하는 Resource들이 있다. 보통 이러한 Resource는 AutoCloseable 을 상속받는 Closeable 을 구현하고 있다. 이러한 리소스는 최종적으로 리소스에 대한 레퍼런스가 없어질 때, GC가 알아서 처리하지만 굉장히 느린 작업이고 비용이 비싸다. 그러므로 명시적으로 close 메서드를 호출해주는것이 좋은데, 자바를 사용할 때 try-with-resources를 사용했던 것 처럼 코틀린에서 use를 사용하도록 하라. 예제 use 는 아래와 같이 Closeable 를 구현한 객체에 사용할 수 있다. f..

스터디/이펙티브코틀린

아이템 8 - 적절하게 null을 처리하라

null은 ‘값이 부족하다’를 나타내며 상황에 따라 다음을 의미한다. 값이 설정되지 않았다. 값이 제거되었다. 따라서 null은 명확한 의미를 가지도록 하는 것이 좋다. nullable 타입을 다루는 방법 다음 세가지 방법으로 다룬다. 안전호출(?.), 스마트 캐스팅, 엘비스(Elvis ?:) 연산자 오류를 throw 리팩토링을 통해 nullable 제거 null을 안전하게 처리하기 아래 두가지 방법은 애플리케이션 사용자 관점에서 가장 안전한 방법이다. 안전호출을 사용하기 val printer: Printer? = getPrinter() printer?.print() val printerName1 = printer?.name ?: "Unnamed" val printerName2 = printer?.nam..

스터디/이펙티브코틀린

아이템 7 - 결과 부족이 발생할 경우 null과 Failure를 사용하라

다른 시스템에서 데이터를 인터넷 연결등의 이유로 받아오지 못하는 경우 조건에 맞는 요소를 찾지 못하는 경우 파싱을 시도했으나 형식이 맞지않아 실패하는 경우 위와 같이 함수가 원하는 결과를 만들어 내지 못할 때 예외를 정보를 전달하는 방법으로 사용해서는 안된다. 다음과 같은 방식을 고려하자. 충분히 예측할 수 있는 범위의 오류 null, 실패를 나타내는 sealed 클래스를 반환한다. null을 반환하는 경우: 추가적인 정보를 전달하지 않아도 되는 경우 sealed 클래스를 반환하는 경우: 추가적인 정보를 전달해야 하는 경우 예측하기 어려운 경우 예외를 throw 한다. 예외를 정보를 전달하는 방법으로 사용하면 다음과 같은 문제가 발생하기 때문이다. 개발자가 exception이 전파되는 과정을 제대로 추적..

스터디/이펙티브코틀린

아이템 6 - 사용자 정의 오류보다는 표준 오류를 사용하라

JSON 형식을 파싱하는 부분에 문제가 있다면 이를 코틀린의 표쥰 오류로 표현하기 어려울 수 있다. 이러한 경우 보통 사용자 정의 오류를 새로 생성해서 사용한다. 하지만 가능하다면, 직접 오류를 정의하지 말고 최대한 표준 라이브러리의 오류를 사용하도록 하자. 표준 라이브러리의 오류는 널리 알려질 규약이기 때문에 다른 사람이 API를 더 쉽게 배우고 이해할 수 있다. 대표적인 예외는 다음과 같다. IllegalArgumentException IllegalStateException IndexOutOfBoundsException ConcurrentModificationException UnsupportedOperationException NoSuchElementException 위 Exception중 Unsu..

스터디/이펙티브코틀린

아이템 5 - 예외를 활용해 코드에 제한을 걸어라

require : 아규먼트를 제한한다. check : 상태와 관련된 동작을 제한한다. assert : 어떤것이 true인지 확인한다. test 모드에서만 작동한다. return, throw와 함께 활용하는 엘비스(Elvis) 연산자 위 블럭을 이용하면 다양한 장점을 갖게 된다. require과 check 블럭을 통해 문서를 통하지 않고도 어느정도 요구사항을 파악할 수 있고 예상치 못한동작을 방어할 수 있게된다. 그리고 스마트 캐스트 기능을 활용할 수 있게 되면서 타입 변환을 적게 할 수 있다. 아래는 스터디를 하면서 구성원들과 이야기한 내용을 정리한 것이다. require 매개변수로 받은 값이 유효한지 검사하는 용도로 사용하는것이 올바른 것 같다. 예를들어 전달받은 Long이 양수여야만 하는지 검사를 하..

스터디/이펙티브코틀린

아이템 4 - inferred 타입으로 리턴하지 말라

코틀린은 타입추론을 지원한다. 이 때 주의할 점이 있다. 먼저 추론된(inferred)타입은 정확하게 오른쪽에 있는 피연산자에 맞게 설정된다. 따라서 슈퍼클래스 혹은 인터페이스로 설정되지 않음을 기억해야한다. 따라서 원하는 타입보다 제한된 타입으로 설정됐다면 명시적으로 타입을 지정해주어야 한다. 외부에 제공하는 라이브러리의 인터페이스 반환 타입을 명시적으로 지정하다 제거해버리면 사용을 하는 쪽에서 문제가 발생 할 수 있다. 따라서 안전을 위해 외부 제공 API를 만드는 경우 반드시 타입을 지정하고, 지정한 타입을 변경하거나 제거하지 않아야 한다. 책에서 나온 예시와 같이 명시적 타입을 제거함으로써 인터페이스 구현체에서 더 이상 Car가 아닌 Ferrari 구현체만 반환하는 인터페이스가 되버린다. 결론 타..

스터디/이펙티브코틀린

아이템 3 - 최대한 플랫폼 타입을 사용하지 말라

코틀린의 주요 기능 중 하나인 널 안정성 덕분에 자바를 사용하면서 자주 보던 NullPointerException을 덜 볼 수 있게 되었다. 하지만 널 안정성 기능이 없는 타 언어(Java, C) 등과 코틀린을 같이 사용하고 코틀린이 다른 언어를 이용하여 사용하는 경우 널 안정성이 보장되지 않아 NullPointerException을 만나게 될 수 있다. 자바의 경우 String 반환 타입에 어노테이션으로 @NotNull 혹은 @Nullable 의 존재 유무로 코틀린에서 String으로 사용할지 String? 으로 사용할지 구분지을수 있다. 하지만 어노테이션이 붙어있지 않다면 기본적으로 nullable 할수 있기 때문에 String? 으로 가정하고 다루어야 한다. 그러니 자바와 코틀린을 함께 사용하는 상..