본문 바로가기
프로그래밍 놀이터/Kotlin, Coroutine

[Effective Kotlin] Item 44: Avoid member extensions

by 돼지왕 왕돼지 2022. 5. 30.
반응형

이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서
Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다.

 

#

interface PhoneBook{
	fun String.isPhoneNumber(): Boolean
}

class Fizz: PhoneBook{
	override fun String.isPhoneNumber(): Boolean { /../ }
}

위와 같은 구현이 가능하지만 피하는 것이 좋다. (DSL 제외)

 

#
특히 extension 을 visibility control 이슈로 member 로 정의하면 안 된다.

class PhonebookIncorrect{
	fun String.isPhoneNumber():Boolean { /../}
}

실제 이렇게 정의한다고 해도 visibility 제한이 걸리지 않는다.
오히려 사용을 어렵게만 만든다.

PhonebookIncorrect().apply{ "1234567890".isPhoneNumber() }

visibility control 은 modifier 로 해야지 local 에 넣음으로 구현하면 안 된다.

class PhonebookCorrect{ /../ }

private fun String.isPhoneNumber():Boolean { /../ }

 

#
member extension 은 reference 가 되지 않는다.

val ref = PhoneBookIncorrect::isPhoneNumber // error
val boundedRef = PhoneBookIncorrect()::isPhoneNumber // error

 

#
2개의 receiver 에 접근하는 것이 혼란을 야기할 수 있다.

class A{
	val a = 10
}

class B{
	val b = 10
    
	fun A.test() = a + b
}

 

#

modify 를 가할 때, 해당 class 를 modify 하는지 receiver 것을 modify 하는지 햇갈린다.

class A { /../}

class B {
	// ...
	fun A.update() = ...
}

 

#

결론적으로 경험이 부족한 개발자들이 어려워하기 딱 좋다.

 

#
최종 결론 : member extension 으로 가져가야 할 합당한 이유가 있는게 아니면 가급적 피하는게 좋다. visibility control 은 local 위치가 아니라 visibility modifier 로 해야 한다.

 

 

 

반응형

댓글