Kotlin/이펙티브코틀린 (4) 썸네일형 리스트형 3장 재사용성 : 23 ~ 25 Item 23. 타입 파라미터의 섀도잉을 피하라 섀도잉이란 // 섀도잉 예시 class Person(val name: String) { fun addName(name: String) { // something } } 코틀린에서는 동일한 이름을 여러번 사용하는 것이 가능하다 addName에서 name은 생성자로 받은 name이 아닌 파라미터로 받은 name을 가리킨다 addName() 내부에서 생성자에 선언된 name을 사용하기 위해서는 this.name으로 명시하여 어느 범위의 name인지 알려줘야 한다 이처럼 같은 이름을 가진 요소에 의해 값이 가려지는 것을 섀도잉이라고 한다 섀도잉은 읽는 사람을 혼란스럽게 하기 때문에 피하는게 좋을 것 같다 혼란스러워지는 예시😱 interface Tree class .. 2장 가독성 : Item 14 - 16 Item 14 : 변수 타입이 명확하지 않은 경우 확실하게 지정하라 코틀린에는 타입 추론 시스템이 있지만, 타입이 명확하지 않은 경우 남용하면 좋지 않다 예시 val data = getSomeData() 코드 정의로 쉽게 이동할 수 없는 깃허브 등의 환경에서 코드를 읽는 사람도 고려해야 한다 이는 가독성을 위함도 있지만, 안전을 위해서도 타입을 지정하는 것이 좋다 Item 15 : 리시버를 명시적으로 참조하라 스코프 내부에 둘 이상의 리시버가 있는 경우 리시버를 명시적으로 나타내면 좋다 apply, with, run 등의 스코프함수를 사용할 때가 대표적인 예시이다. 잘못 사용한 예시 class Node(val name: String) { fun makeChild(childName: String) = cr.. item 6~10 안정성에 관련된 내용 이어서 Item 6 : 사용자 정의 오류보다는 표준 오류를 사용하라 직접 오류를 정의하기 보다는 표준 라이브러리 오류를 사용하는 것이 좋다 당연한 이야기지만 문제가 발생했을 때, 그게 잘 알려진 문제라면 해결한 사람도 많을 것이기 때문에 도움받기 쉽다 Item 7 : exception의 대체, null과 failure를 사용하라 exception을 남발해선 안된다 단순히 정보 전달의 목적으로 사용해선 안되고 정말 예외적인 상황이 발생했을 때 사용하여 적절한 처리가 이루어지도록 해야 한다 예외를 던지지 않고 예측할 수 있는 범위의 오류를 표현하는 방법 1. null 리턴 getOrNull : 리스트에서 값이 있으면 값을 반환하고 없으면 null을 반환하는 함수. IndexOutOfBo.. 1장 : item 1 1장은 안정성을 주제로 10가지 아이템을 다루고 있다. Item 1 : 가변성을 제한하라 가변성을 제한하는 이유 많은 부분에서 변화가 생기면 디버깅이 어려워진다 테스트하기 어렵다 멀티스레드 환경일 경우 동기화가 필요한데, 변경이 많을수록 충돌 지점도 많아진다 가변성 제한 방법 kotlin에서 가변성을 제한하기 위해서 보통 immutable(읽기전용) 객체, 컬렉션을 사용한다. val : immutable 프로퍼티 사용 immutable 컬렉션 mutable 컬렉션과 구분하여 사용 data class의 copy 활용하기 val : 읽기 전용 프로퍼티 사용하기 val 가 붙은 프로퍼티는 읽기 전용이지만 가변성 존재한다. 예를 들면 mutable 객체를 담고 있을 경우가 그렇다. 그럼에도 var 대신 val를.. 이전 1 다음