본문 바로가기
[Effective Kotlin] Item 38 : Use function types instead of interfaces to pass operations and actions 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # fun setOnClickListener(listener: (View) -> Unit) { /../ } setOnClickListener { /../ } setOnClickListener(fun(view){ /../ } setOnClickListener(::println) setOnClickListener(this::showUsers) 위와 같은 적용이 가능하다. interface 로 정의해야 할 특별한 이유가 없다면, function type 을 사용하자. When shoul.. 2022. 5. 18.
[Effective Kotlin] Item 37 : Use the data modifier to represent a bundle of data 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # data modifier 를 사용하면 primary constructor 에 대해 자동으로 아래의 작업이 구현된다. toString equals and hashCode copy componentN # destructoring 은 단점이 있다. element 의 순서를 바꾸는 순간 사용하는 곳 모두 순서를 바꿔줘야 할 수 있다. IDE 가 warning 을 표시하도록 하기 위해, 변수이름을 같이 해주는 것이 최소한의 대책일 수 있다. Prefer data classes inste.. 2022. 5. 17.
[Effective Kotlin] Item 36 : Prefer composition over inheritance 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # 상속은 강력한 기능이다. 하지만 이것은 is-a 관계의 계층을 만들기 위해 디자인 되었다는 것을 명심하고 사용해야 한다. 이 관계가 확실하지 않으면 상속은 문제를 야기할 수 있고 위험하다. 대안으로 class composition 이 선호된다. Simple behavior reuse # 상속은 다음의 문제를 갖는다. 1개의 class 만 상속 가능하다. 상속하면, 해당 class 의 모든 것을 가져온다. (불필요한것 포함) superclass 의 기능 사용의 명시성이 떨어진다... 2022. 5. 16.
[Effective Kotlin] Item 35 : Consider defining a DSL for complex object creation 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # HTML, View hierarchy, config 등등 많은 케이스에 적용될 수 있다. 돼왕 : 선언적인 느낌을 주기 좋은 것 같다. # 만들기 복잡한 계층구조를 이루는 data 구조의 경우 DSL 로 하면 간단할 수 있다. DSL 로 하면 Groovy 와 다르게 type safe 를 이룩할 수 있다. Defining your own DSL # function type with receiver 의 개념을 이해해야 DSL 을 만들 수 있다. # function type 을 만드.. 2022. 5. 15.
[Effective Kotlin] Item 34 : Consider a primary constructor with named optional arguments 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. Telescoping constructor pattern # Kotlin 에서는 default arguments 지정으로 primary constructor 하나만 정의하면서 이를 대체할 수 있다. Builder pattern # default argument & named parameter 조합이 builder 보다 좋다. 코드가 더 짧고, 수정도 더 간단하다. 훨씬 깔끔하다. 어떻게 object 가 생성되는지는 constructor 하나만 보면 된다. 사용하기가 더 쉽다. pr.. 2022. 5. 6.
[Effective Kotlin] Item 33 : Consider factory functions instead of constructors 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # Factory function 의 장점은 아래와 같다. Constructor 와 다르게 이름을 가질 수 있다. Constructor 와 다르게 subtype 을 return 할 수 있다. Constructor 와 다르게 매번 새로운 object 를 만들지 않아도 된다. 기존에 만든 것을 줄 수도 있고, null 을 return 할 수도 있다. 아직 존재하지 않는 object 를 제공할 수 있다. 이는 annotation processing 기반으로 객체가 생성되는 경우를 이야기.. 2022. 5. 5.
[Effective Kotlin] Item 32 : Respect abstraction contracts 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # reflection 으로 private field 와 function 등에 접근할 수는 있지만, 이것을 해도 된다는 건 아니다. 그들은 constract 의 일부가 아니다. 그래서 언제든 그 구현 등이 바뀔 수 있다. 그래서 이는 매우 위험하다. Contracts are inherited # 예를 들면 Any 는 hashCode, equals 를 구현하길 기대한다. Summary # Contract 를 존중하자. 만약 이를 깨야만 한다면 문서화 해놓자. 끝 2022. 5. 4.
[Effective Kotlin] Item 31 : Define contract with documentation 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # 이름이 말하는 바가 불투명하거나 문서화가 제대로 되어 있지 않다면, 개발자는 원래 의도가 아닌 현재 구현을 바탕으로 판단한다. Contract # 규약이 잘 정의되어 있다면, 제작자 측면에서 이 녀석이 어떻게 사용될지 걱정할 필요가 없어지고, 사용자 입장에서는 어떻게 구현되었는지를 신경쓸 필요가 없어진다. 만약 규약이 잘 정의되어 있지 않다면, 유저는 무엇을 해도 되는지 하면 안 되는지 잘 몰라서 구현을 보고 이를 따르게 된다. 제작자는 유저가 무엇을 원하는지 모르기 때문에 추.. 2022. 5. 3.
[Effective Kotlin] Item 30 : Minimize elements visibility 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # 적은 interface 는 학습 난이도를 낮추고, 유지보수도 쉬워진다. 새로운 것을 노출하는 것은 쉽지만, 기존에 노출한 것을 감추기는 어렵다. 감추기 위해서는 보통 대체제를 제시해 주어야 한다. # property 를 노출하는 것은 class 자체의 안정성을 낮추는 효과가 난다. 덜 공개할수록 클래스의 변화를 추적하기 쉽다. Using visibility modifiers # 지금 당장 쓰지 않는 property 라도 그 속성을 나타내는 것이면 public 으로 두어도 된다... 2022. 5. 2.
반응형

티스토리툴바