본문 바로가기

Reading Record

ㅤㅤㅤㅤㅤ
By gobukgol
[이펙티브 코틀린] Item23. 타입 파라미터의 섀도잉을 피하라 class Forest(val name: String) { fun addTree(name: String){ } } 위의 코드 처럼 프로퍼티와 파라미터가 같은 이름을 가질 수 있다. 이렇게 되면 지역 파라미터가 외부 스코프에 있는 프로퍼티를 가림. 이를 섀도잉 이라 부른다. 섀도잉 현상은 클래스 타입 파라미터와 함수 타입 파라미터 사이에서도 발생 interface Tree class Birch: Tree class Spruce: Tree class Forest { fun addTree(tree: T) { println("adding tree ...") } } fun main() { val forest = Forest() forest.addTree(Birch()) forest.addTree(Spruce()).. Reading Record/이펙티브 코틀린 2022. 5. 1.
ㅤㅤㅤㅤㅤ
By gobukgol
[이펙티브 코틀린] Item22. 일반적인 알고리즘을 구현할 때 제네릭을 사용하라 제네릭 함수 : 타입 아규먼트를 사용하는 함수 즉, 타입 파라미터를 갖는 함수를 얘기한다. 타입 파라미터는 컴파일러에 타입과 관련된 정보를 제공하여 컴파일러가 타입을 조금이라도 더 정확하게 추측할 수 있게 해준다. 컴파일 과정에서 타입 정보는 사라지지만 개발 중에는 특정 타입을 사용하게 강제할 수 있다. 제네릭 제한 타입 파라미터의 기능 중 하나로 구체적인 타입의 서브타입만 사용하게 타입을 제한한다. public fun Iterable.toCollection(destination: C): C { for (item in this) { destination.add(item) } return destination } Any를 이용하여 nullable이 아닌 타입을 나타내는 케이스 public inline fu.. Reading Record/이펙티브 코틀린 2022. 5. 1.
ㅤㅤㅤㅤㅤ
By gobukgol
[이펙티브 코틀린] Item21. 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라 코틀린은 프로퍼티 위임이라는 새로운 기능을 제공 프로퍼티 위임을 사용하면 일반적인 프로퍼티의 행위를 추출해서 재사용할 수 있다. 대표적으로 지연 프로퍼티인 lazy 프로퍼티가 존재 처음 사용하는 요청이 들어올 때 초기화 되는 프로퍼티 val value by lazy { createValue() } 변화가 있을 때 이를 감지하는 observable 패턴, stdlib의 observable 델리게이트 기반으로 구현 가능 var items: List by Delegates.observable(listOf()) { _, _, _ -> notifyDataSetChanged() } var key: String? by Delegates.observable(null) { _, old, new -> Log.e("Key .. Reading Record/이펙티브 코틀린 2022. 5. 1.
ㅤㅤㅤㅤㅤ
By gobukgol
[이펙티브 코틀린] Item20. 일반적인 알고리즘을 반복해서 구현하지 말라 이미 구현되어있는 알고리즘을 활용했을 때의 장점 단순하게 코드가 짧아진다. 코드 작성 속도가 빨라진다. 알고리즘을 만드는 것보다 함수 호출을 한 번 하는 것이 훨씬 빠르다 구현을 따로 읽지 않아도, 함수의 이름 등만 보고도 무엇을 하는지 확실하게 알 수 있다. 그만큼 함수의 이름도 잘 작성해야한다. 직접 구현할 때 발생할 수 있는 실수를 줄일 수 있다. 이미 구현되어있는 함수를 제작자들이 한 번만 최적화하면, 해당 함수를 사용하는 모든 곳이 최적화의 혜택을 받을 수 있다. 표준 라이브러리인 stdlib를 활용하자. stdlib는 확장 ㅎ마수를 활용해서 만들어진 거대한 유틸리티 라이브러리 동일한 결과를 얻는 함수를 여러 번 만드는 것은 잘못된 일 모든 함수는 테스트되어야하고, 기억되어야 하며, 유지보수되어.. Reading Record/이펙티브 코틀린 2022. 5. 1.
ㅤㅤㅤㅤㅤ
By gobukgol
[이펙티브 코틀린] Item19. knowledge를 반복하여 사용하지 말라 프로그래밍에서의 knowledge란? 의도적인 정보 프로젝트를 진행할 때 정의한 모든 것 ex. 상속을 하는데도 특정 메소드를 오버라이드하지 않게 강제 -> '해당 메소드가 슈퍼클래스와 동일하게 동작하길 원한다' 라는 의미 프로그램에서 중요한 2개의 knowledge 로직(logic) : 프로그램이 어떤 식으로 동작하는지, 어떻게 보이는지 공통 알고리즘(common algorithm) : 원하는 동작을 하기 위한 알고리즘 두가지의 차이는 시간에 따른 변화 비즈니스 로직은 시간이 지나면서 계속 변화 공통 알고리즘은 한 번 정의된 이후에 크게 변하지 않음 많은 것이 변화하는 상황에서 가장 위험한 것은 knowledge가 반복되어 있는 부분 knowledge의 반복은 프로젝트의 확장성(scalable)을 막고.. Reading Record/이펙티브 코틀린 2022. 5. 1.
ㅤㅤㅤㅤㅤ
By 쟈 미
[이펙티브 코틀린] Item18. 코딩 컨벤션을 지켜라 지켜야하는 이유 어떤 프로젝트를 접해도 쉽게 이해할 수 있다 다른 외부 개발자도 프로젝트의 코드를 쉽게 이해할 수 있다 다른 개발자도 코드의 작동 방식을 쉽게 추측할 수 있다 코드를 병합하고, 한 프로젝트의 코드 일부를 다른 코드로 이동하는 것이 쉽다 컨벤션 두가지 도구 intellij 포매터 ktlink 파라미터 컨벤션 코틀린에서 많은 파라미터를 갖고있는 클래스, 함수는 각각의 파라미터를 한 줄씩 작성하는 방법을 사용한다 class Person( val id: Int =0, val name: String ="", val surname: String = "" ): Human(id,name) public fun Iterable.joinToString( separator: CharSequence = ", ".. Reading Record/이펙티브 코틀린 2022. 4. 26.
ㅤㅤㅤㅤㅤ
By 쟈 미
[이펙티브 코틀린] Item17. 이름 있는 아규먼트를 사용하라 이름있는 아규먼트 (named argument) - 파라미터가 명확하지 않은 경우에는 이를 집적 지정해서 명확하게 만들어준다. 이름있는 아규먼트의 장점 이름을 기반으로 값이 무엇을 나타내는지 알 수 있다 파라미터 입력 순서와 상관이 없어 안전하다. 성능에 영향을 줄 것 같으면, 인라인 클래스를 사용하라 : 그러나 파라미터 순서 잘못 입력하는 경우 생길 수 있다. 이름 있는 아규먼트를 사용해야하는 경우 3가지 1) 디폴트 아규먼트의 경우 함수 이름은 필수 파라미터들과 관련되어있어, 디폴트 값을 갖는 옵션 파라미터(optional parameter)의 설명이 명확하지 않다. 2) 같은 타입의 파라미터가 많은 경우 이름있는 아규먼트를 사용하지 않으면 잘못 입력했을 때 문제를 찾아내기 어려울 수 있다. 3) 함.. Reading Record/이펙티브 코틀린 2022. 4. 26.
ㅤㅤㅤㅤㅤ
By 쟈 미
[이펙티브 코틀린] Item16. 프로퍼티는 동작이 아니라 상태를 나타내야 한다. 자바의 필드와 코틀린의 프로퍼티는 완전 다른 개념이다. 프로퍼티의 특징 1 ) 프로퍼티는 사용자 정의 세터와 게터를 가질 수 있다. field 식별자 : 프로퍼티의 데이터를 저장해두는 백킹 필드(backing field)에 대한 레퍼런스 > 세터와 게터의 디폴트 구현에 사용 2 ) 파생 프로퍼티 (derrived property) var을 사용해서 만든 읽고 쓸 수 있는 프로퍼티는 게터와 세터 정의가 가능하다. val로 읽기 전용 프로퍼티를 만들때는 field가 만들어지지 않는다 3 ) 프로퍼티는 필드가 필요가 없다. 개념적으로 접근자를 나타낸다 (val 는 게터, var는 게터와 세터) 그래서 인터페이스에서 프로퍼티 정의가 가능 프로퍼티 위임 (property delegation)이 가능하다 확장 프로.. Reading Record/이펙티브 코틀린 2022. 4. 26.

티스토리툴바