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

---

아이템 1. 가변성을 제한하라

(가능하면) var 보다는 val 사용
(가능하면) mutable 프로퍼티보다는 immutable 프로퍼티 사용
mutable 객체를 외부에 노출하지 말자.

class Test {
    fun calculate(): Int {
        println("Cal...")
        return 42
    }

    val fizz = calculate()
    val buzz
        get() = calculate()

}

fun main() {
    println(Test().buzz)
}

//Cal...
//Cal...
//42

읽기 전용 컬렉션을 Mutable 컬렉션으로 다운캐스팅 하면 안된다.

읽기 전용에서 mutable로 변경해야 한다면, 복제를 통해 새로운 mutable 컬렉션을 생성하자.

val list = listOf(1, 2, 3)
val mutableList = list.toMutableList()

 

mutable 객체는 예측하기 어려우며 위험하다는 단점이 있고, immutable 객체는 변경할 수 없다는 단점이 있다.

따라서, immutable 객체는 자신의 일부를 수정한 새로운 객체를 만들어내는 메서드를 가져야 한다.

 

Int는 immutable이지만 내부적으로 plus(), minus() 등 자신을 수정한 새로운 Int를 리턴한다.

public operator fun plus(other: Int): Int

 

우리가 직접 만드는 immutable 객체도 위와 비슷한 형태로 작동해야 합니다.

data class User(val name: String, val surname: String) {
    fun witName(name: String) = User(name, surname)
}

---

아이템 2. 변수의 스코프를 최소화하라

프로그램을 추적하고 관리하기 쉽기 때문이다.
변수를 정의할 때 초기화되는 것이 좋다.

// 나쁜 예시
var user: User
for(i in users.indices){
    user = users[i]
    print("User at $i is $user")
}


// 조금 좋은 예시
for(i in users.indices){
    var user = users[i]
    print("User at $i is $user")
}


// 좋은 예시
for((i, user) in users.withIndex()){
    print("User at $i is $user")
}

---

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

플랫폼 타입: 다른 프로그래밍 언어에서 전달되어 nullable인지 아닌지 알 수 없는 타입

• 코틀린의 주요 기능 중 하나는 Null-Safety 이다.
• 플랫폼 타입은 사용하는 코드 외 활용하는 곳까지 영향을 줄 수 있으므로 가급적 제거하는 것이 좋다.
• 코틀린의 nullable -> ?, not null -> !!

---

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

• 코틀린 타입 추론시 잊지 말아야 할점은 inferredType은 정확히 우측에 있는 피연산자에 맞는 타입이 설정된다는 것이다.
• 추가적으로 코틀린에서 타입 추론은 변수 초기화시 그 타입을 추론한다.
• 자바도 자바10부터 타입 추론을 도입하여 지원한다.
• 타입을 확실하게 지정해야 하는 경우에는 명시적으로 타입을 지정해야 한다는 원칙을 가지자. (공개 API, 라이브러리 등)

---

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

확실하게 어떤 형태로 동작해야 하는 코드가 있다면, 예외를 활용해 제한을 걸어주는 것이 좋다.

코틀린에서는 코드의 동작에 제한을 걸 때 다음 키워드를 사용할 수 있다.

• require: 아규먼트 제한
• check: 상태와 관련된 동작 제한
• assert: 어떤 것이 true인지 확인할 수 있고, 테스트 모드에서만 작동

fun decode(encoded: ByteArray): ByteArray {
    require(isBase62Encoding(encoded)) { "Input is not encoded correctly" }

    val prepared = translate(encoded, lookup)

    return convert(prepared, TARGET_BASE, STANDARD_BASE)
}

위와 같은 제약사항에 대한 장점은?

• 문서를 읽지 않은 개발자도 예상되는 문제를 확인할 수 있다.
• 예상하지 못한 동작을 하는 것은 예외를 throw하는 것보다 위험하고, 상태를 관리하는 것이 힘들다.
• 코드가 어느정도 자체적으로 검증이 된다.

아규먼트 (require)

• 함수를 정의할 때 타입 시스템을 활용해서 아규먼트에 제한을 거는 코드
• IllegalArgumentException을 throw한다.

 

상태 (check)

구체적인 조건을 만족할 때만 함수를 사용할 수 있게 해야 할 때,

• 어떤 객체가 미리 초기화가 되어 있어야만 처리를 하게 하고 싶은 함수
• 사용자가 로그인을 했을때만 처리를 하게 하고 싶은 함수
• 객체를 사용할 수 있는 시점에 사용하고 싶은 함수
• IllegalStateException을 throw한다.

 

assert

• 일반적으로 단위 테스트에서 사용
• 프로덕션 환경의 코드에서도 사용이 가능

// 단위 테스트
assertThat(...)
assertEquals(...)

// 프로덕션 코드
fun pop(index: Int, numbers: MutableList<Int>) {
    val size = numbers.size
    numbers.removeAt(index)

    assert(size == numbers.size)
}

---

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

표준 라이브러리의 예외를 사용하면 다음과 같은 이점이 있다:

• 대부분의 개발자가 이미 잘 알고 있는 예외들이다.
• API를 더 쉽게 이해하고 사용할 수 있다.
• 예외 처리에 대한 일관성을 유지할 수 있다.

커스텀 예외가 필요한 경우는?

• 표준 라이브러리의 예외로 표현하기 까다로운 경우
• 특정 비즈니스 도메인에 특화된 예외가 필요한 경우
• 보상 트랜잭션, 재시도 등이 필요한 경우
• 클라이언트 분기 처리를 위한 에러 코드 활용

---

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

결과 부족을 처리하는 두 가지 방법

 

1. null 또는 Failure 반환

• null: 결과가 없음을 나타내기 위해 리턴
• Failure: sealed class를 사용해 실패 상태를 명확하게 표현 (Success, Failure)
• 장점: Failure를 사용하면 실패 원인을 담을 수 있고, when을 통해 상태를 명확하게 분리하여 처리할 수 있다.
• 단점: null은 명시적이지 않고, NPE(Null Pointer Exception) 발생의 위험이 있다.

2. 예외 throw

• 장점: 예외를 던지면 호출자에게 오류가 전달되며 처리가 강제된다.
• 단점: 예외는 프로그램 흐름을 방해하고, 무분별하게 사용하면 코드의 가독성이 저하될 수 있다.

+ 추가

Success, Failure 를 의미하는 코틀린의 Result 클래스

try-catch 대신 사용할 수 있는 코틀린의 runCatching

---

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

null은 최대한 명확한 의미를 갖는 것이 좋다.

String.toIntOrNull() // String을 Int로 적절하게 변환할 수 없으면 null 리턴
Iterable<T>.firstOrNull(() → Boolean) // 주어진 조건에 맞는 요소가 없으면 null 리턴

 

nullable 타입을 처리할 수 있는 방법

• ?.(safe call), 스마트 캐스팅, Elvis 연산자 등 활용
• 오류 throw
• 함수, 프로퍼티를 리팩터링해서 nullable 타입이 나오지 않게 바꾼다.

not-null assertion (!!) 

• !! 을 사용하면 자바에서 nullable을 처리할 때 발생할 수 있는 NPE 문제가 동일하게 발생한다.
• 확실한 상황이 아니라면 사용을 지양하자.

의미 없는 nullability 피하기

nullability는 어떻게든 적절하게 처리해야 하므로 추가 비용이 발생하기에 가능하다면 사용하지 않는 것이 좋다.

• 클래스에스 nullability에 따라 여러 함수를 만들어서 제공할 수 있다. (List<T> 의 get, getOrNull)
• 어떤 값이 클래스 생성 이후 값이 설정된다는 보장이 있다면, lateinit 프로퍼티와 notNull 델리게이트를 사용하라.
• 컬렉션에서는 null이 아닌 빈 컬렉션을 반환하라.

 

lateinit 프로퍼티

• 나중에 속성을 초기화할 수 있는, lateinit 한정자 → 프로퍼티가 이후 설정될 것임을 명시하는 한정자
• 즉, 처음 사용하기 전에 반드시 초기화가 되어 있을 경우에만 사용
• 의도치 않게 사용되어 예외가 발생한다면, 그 사실을 알아야 하므로 예외가 발생하는 것은 오히려 좋은 일

---

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

코틀린/JVM에서 사용하는 자바 표준 라이브러리 중 더 이상 필요하지 않을 때 close 메서드를 사용해서 명시적으로 종료를 해야하는 리소스가 있다.

• InputStream, OutputStream
• java.sql.Connection
• Java.io.Reader 

위의 리소스는 최종적으로 레퍼런스가 없어질 때 GC가 처리하지만, 쉽게 처리되지 않고 느리며 Resource Leak과 같은 문제도 발생할 여지가 있다.

// 가독성
fun countCharactersInFile(path: String): Int {
    val reader = BufferedReader(FileReader(path))
    try {
        return reader.lineSequence().sumOf { it.length }
    } finally {
        reader.close() // 예외 발생할 수 있음
    }
}

 

try-finally 대신 use() 사용하라는 경고

 

fun countCharactersInFile(path: String): Int {
    val bufferedReader = BufferedReader(FileReader(path))
    bufferedReader.use { reader ->
        return reader.lineSequence().sumOf { it.length }
    }
}

// 개선 1.
fun countCharactersInFile(path: String): Int {
    BufferedReader(FileReader(path)).use { reader ->
        return reader.lineSequence().sumOf { it.length }
    }
}

// 개선 2.
fun countCharactersInFile(path: String): Int {
    File(path).useLines { lines ->
        return lines.sumOf { it.length }
    }
}

---

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

단위 테스트를 통해 확인할 수 있는 정보

• 일반적인 유스 케이스(happy path)
• 일반적인 오류 케이스와 잠재적인 문제 (fail)
• 예외 케이스와 잘못된 아규먼트 (range, nullable, ...)

@Test
fun `유효하지 않은 인덱스에 접근하면 예외가 발생해야 한다`() {
    val numbers = listOf(1, 2, 3, 4, 5)

    // 유효하지 않은 인덱스(예: 인덱스 10)는 예외를 발생시켜야 한다.
    assertThrows(IndexOutOfBoundsException::class.java) {
        get(numbers, 6)  // 범위 밖의 인덱스
    }
}