이펙티브 코틀린 - 3장 재사용성

---

아이템 19. knowledge(의도적인 정보)를 반복하여 사용하지 말라

필자가 생각하는 프로그래밍의 가장 큰 규칙은?

• 프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다.

프로그램에서 중요한 knowledge 두 가지?

1. 로직: 프로그램이 어떤 식으로 동작하는지와 프로그램이 어떻게 보이는지
2. 공통 알고리즘: 원하는 동작을 하기 위한 알고리즘

비즈니스 로직은 시간이 지나면서 계속 변하지만, 공통 알고리즘은 한 번 정의된 후 크게 변하지 않는다.

class Student {
    fun isPassing(): Boolean = ...
    fun qualifiesForScholarship(): Boolean = ...
	
    private fun calculatePointsFromPassedCousre(): Int { ... }
}

위 Student 클래스는 서로 다른 두 부서에서 사용중인 클래스인데, 요구사항이 변경되어 기존 함수들이 수정된다면, 관련 없는 기능에서 이슈가 발생할 수 있다. (탄탄한 단위 테스트가 어느정도 커버는 가능할 것 같다.)

 

StudentIsPassingValidator, StudentQualifiesForScholarshipValidator 등의 클래스를 구분해서 활용할 수 있겠다.

또한 코틀린의 확장 함수를 활용하면, 두 함수는 Student 클래스 아래에 두면서 각 부서가 관리하는 서로 다른 모듈의 파일에 배치할 수 있다.

// A 모듈
fun Student.qualifiesForScholarship(): Boolean {
    ...
}

// B 모듈
fun Student.isPassing(): Boolean = {
    ...
}

 

헬퍼 함수는 private 함수로 만들지 않고 다음과 같이 만드는 것이 일반적이다.

• 두 부서에서 모두 사용하는 일반적인 public 함수로 헬퍼 함수를 만든다. 또한 공통적인 부분은 두 부서에서 모두 사용하므로, 이를 함부로 수정할 수 없도록 규약을 정한다.
• 헬퍼 함수를 각각의 부서 모듈에 따라 2개 만든다.

 

단일 책임 원칙(SRP)은 우리에게 두 가지 사실을 알려준다.

• 서로 다른 곳(부서)에서 사용하는 knowledge는 독립적으로 변경할 가능성이 많다. 따라서 비슷한 처리를 하더라도 완전히 다른 knowledge로 취급하는 것이 좋다.
• 다른 knowledge는 분리해 두는 것이 좋다. 그렇지 않으면 재사용하려는 유혹이 발생할 수 있다.

---

아이템 20. 일반적인 알고리즘을 반복해서 구현하지 말라

// Bad
override fun saveCallResult(item: SourceResponse) {
	var sourceList = ArrayList<SourceEntity>()
	item.sources.forEach {
		var sourceEntity = SourceEntity()
		sourceEntity.id = it.id
		sourceEntity.category = it.category
		...
	}
	
	db.insertSources(sourceList)
}

// Good
override fun saveCallResult(item: SourceResponse) {
	var sourceEntries = item.sources.map(::sourceToEntry)
	db.insertSources(sourceEntries)
}

private fun sourceToEntry(source: Source) = SourceEntity()
	.apply {
		id = source.id
		category = source.category
		...	
}

 

모든 함수는 테스트가 되어야 하고, 기억되어야 하며, 유지보수가 되어야 한다. -> 비용 고려

 

확장 함수가 가지는 장점들?

• 함수는 상태를 유지하지 않으므로 행위를 나타내기 좋다.
• 톱레벨 함수와 비교해서 확장 함수는 구체적인 타입이 있는 객체에만 사용을 제한할 수 있으므로 좋다.
• 수정할 객체를 아규먼트로 전달받아 사용하는 것보다 확장 리시버로 사용하는 것이 가독성 측면에서 더 좋다.
• IDE의 자동완성 도움을 받아 쉽게 찾을 수 있다.

// (1) String이라는 상태를 가진 객체에 isEmail()이라는 순수한 행위만 추가한 형태입니다.
fun String.isEmail(): Boolean = this.contains("@") && this.contains(".")
val email = "hello@example.com"
println(email.isEmail())

// (2) List<Int> 타입에만 적용되므로 타입이 명확한 객체에만 호출 가능함.
fun List<Int>.sumOfEven(): Int = this.filter { it % 2 == 0 }.sum()

// (3) removeSpaces(raw)보다 raw.removeSpaces()가 직관적
fun String.removeSpaces(): String = this.replace(" ", "")
val raw = "hello world"
println(raw.removeSpaces())

내가 구현하려는 기능이 이미 오픈소스, 라이브러리 등에 존재하지 않는지 잘 찾아보는 것도 중요하다. 특히 guava, apache 등의 오픈소스에는 굉장히 유용한 라이브러리들이 굉장히 많기에 평소에 잘 챙겨보는 것이 중요할 것 같다!

---

아이템 21. 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라

코틀린은 코드 재사용과 관련하여 프로퍼티 위임(=프로퍼티 델리게이트)이라는 새로운 기능을 제공한다.

대표적으로 지연 프로퍼티가 있는데, lazy 프로퍼티는 처음 사용하는 요청이 들어올 때 초기화되는 프로퍼티를 의미한다.

val value by lazy { createValue() }

 

위와 같은 프로퍼티 위임을 사용하면, 변화가 있을 때 이를 감지하는 Obserable 패턴을 쉽게 만들 수 있다.

// 목록을 출력하는 리스트 어댑터가 있다면, 내부 데이터가 변경될 때마다 변경된 내용을 다시 출력하거나 로그로 남기는 경우
val items: List<Item> by Delegates.observable(listOf()) { _, _, _ -> notifyDataChanged() }

 

// ### 뷰, 리소스 바인딩, 의존성 주입, 데이터 바인딩

// 안드로이드에서 뷰와 리소스 바인딩
private val button: Button by bindView(R.id.button)
private val textSize by bindDimension(R.dimen.font_size)

// Kotlin에서의 종속성 주입
private val presenter: MainPresenter by inject()
private val repository: NetworkRepository by inject()

// 데이터 바인딩
private val port by bindConfiguration("port")

 

코틀린의 stdlib에서 다음과 같은 프로퍼티 델리게이터를 알아 두자.

• lazy
• Delegates.obserable
• Delegates.vetoable
• Delegates.notNull

 

Delegates 내부 코드

/**
 * Standard property delegates.
 */
public object Delegates {
    /**
     * Returns a property delegate for a read/write property with a non-`null` value that is initialized not during
     * object construction time but at a later time. Trying to read the property before the initial value has been
     * assigned results in an exception.
     *
     * @sample samples.properties.Delegates.notNullDelegate
     */
    public fun <T : Any> notNull(): ReadWriteProperty<Any?, T> = NotNullVar()

    /**
     * Returns a property delegate for a read/write property that calls a specified callback function when changed.
     * @param initialValue the initial value of the property.
     * @param onChange the callback which is called after the change of the property is made. The value of the property
     *  has already been changed when this callback is invoked.
     *
     *  @sample samples.properties.Delegates.observableDelegate
     */
    public inline fun <T> observable(initialValue: T, crossinline onChange: (property: KProperty<*>, oldValue: T, newValue: T) -> Unit):
            ReadWriteProperty<Any?, T> =
        object : ObservableProperty<T>(initialValue) {
            override fun afterChange(property: KProperty<*>, oldValue: T, newValue: T) = onChange(property, oldValue, newValue)
        }

    /**
     * Returns a property delegate for a read/write property that calls a specified callback function when changed,
     * allowing the callback to veto the modification.
     * @param initialValue the initial value of the property.
     * @param onChange the callback which is called before a change to the property value is attempted.
     *  The value of the property hasn't been changed yet, when this callback is invoked.
     *  If the callback returns `true` the value of the property is being set to the new value,
     *  and if the callback returns `false` the new value is discarded and the property remains its old value.
     *
     *  @sample samples.properties.Delegates.vetoableDelegate
     *  @sample samples.properties.Delegates.throwVetoableDelegate
     */
    public inline fun <T> vetoable(initialValue: T, crossinline onChange: (property: KProperty<*>, oldValue: T, newValue: T) -> Boolean):
            ReadWriteProperty<Any?, T> =
        object : ObservableProperty<T>(initialValue) {
            override fun beforeChange(property: KProperty<*>, oldValue: T, newValue: T): Boolean = onChange(property, oldValue, newValue)
        }

}

 

class User {
    var name: String by Delegates.observable("initial") { prop, old, new ->
        println("Property ${prop.name} changed from $old to $new")
    }
}

fun main() {
    val user = User()
    user.name = "Ju"
    user.name = "Hyun"
}

// Property name changed from initial to Ju
// Property name changed from Ju to Hyun

---

아이템 22. 일반적인 알고리즘을 구현할 때 제네릭을 사용하라

타입 아규먼트를 사용하면 함수에 타입을 전달할 수 있는데, 이를 제네릭 함수라고 부른다.

• 컴파일러가 정확한 타입 추측

 

제네릭 제한

• 타입 파라미터의 중요한 기능 중 하나는 구체적인 타입의 서브타입만 사용하게 타입을 제한하는 것

타입(T)에 제한이 걸리므로, 내부에서 해당 타입이 제공하는 메서드를 사용할 수 있다.

 

mapNotNull vs map

mapNotNull

 

map

 

fun main() {
    val items: List<String> = listOf("1", "2", "a", "4", "b")

    val mappedList = items.map { it.toIntOrNull() }
    println("Result of map: $mappedList") // [1, 2, null, 4, null]


    val mappedNotNullList = items.mapNotNull { it.toIntOrNull() }
    println("Result of mapNotNull: $mappedNotNullList") // [1, 2, 4]
}

---

아이템 23. 타입 파라미터의 섀도잉을 피하라

섀도잉은 지역 변수나 파라미터가 동일한 이름을 가진 외부 스코프의 변수를 가리는 현상이다.

class Forest<T> {
    fun addTree(tree: T) {
        // T 타입의 나무를 추가
    }
}

위 코드는 타입 안정성이 부족한데, 어떤 타입의 tree도 다 받을 수 있기 때문이다.

 

class Forest2<T : Tree> {
    fun addTree(tree: T)  {
        // Tree 하위 타입의 T 타입의 나무만 추가
    }
}

fun main() {
    val forest = Forest<Birch>()
    forest.addTree(Birch())   // 가능
    forest.addTree(Spruce())  // 컴파일 오류(type mismatch)
}

따라서 addTree() 함수에서 클래스 타입의 파라미터인 T를 사용하도록 변경해야 한다.

---

아이템 24. 제네릭 타입과 variance 한정자를 활용하라

class Cup<T>

위 코드에서 타입 파라미터 T는 variance 한정자(out 또는 in)가 없으므로, 기본적으로 invariant(불공변성)이다.

invariant는 제네릭 타입으로 만들어지는 타입들이 서로 관련성이 없다는 의미

 

out: 공변성(covariant)

• 자바 제네릭 -> ? extends T

class Cup<out T>
open class Dog
class Puppy : Dog()

fun main() {
    val cupDog: Cup<Dog> = Cup<Puppy>() // OK
    val cupPuppy: Cup<Puppy> = Cup<Dog>() // 오류
}

 

"A가 B의 서브 타입일 때, Cup<A>는 Cup<B>의 서브타입"

 

 

in: 반공변성(contravariant)

• 자바 제네릭 -> ? super T

class Cup<in T>
open class Dog
class Puppy : Dog()

fun main() {
    val cupPuppy: Cup<Puppy> = Cup<Dog>() // OK
    val cupDog: Cup<Dog> = Cup<Puppy>() // 오류
}

"A가 B의 서브 타입일 때, Cup<A>는 Cup<B>의 상위 타입"

 

variance 한정자

 

---