본문 바로가기
[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.
[Effective Kotlin] Item 29 : Consider wrapping external API 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # 안정성이 낮은 외부 라이브러리를 사용할 때 wrap 하는 이유는 아래와 같다. 사용자 입장에서 API 변화에 영향도가 적어진다. 우리 프로젝트 스타일과 로직에 맞도록 API 의 변화가 가능하다. 다른 lib 으로 교체도 유연하진다. 필요에 따라 동작 변경도 가능하다. 이에 따른 단점은 아래와 같다. wrapper 가 사용하는 모든 기능에 대한 정의를 또 해야 한다. Internal API 에 대한 추가 학습이 필요하다. Internal API 에 대한 학습 채널이 없다. # 위.. 2022. 5. 1.
[Effective Kotlin] Item 28 : Specify API stability 이 글은 Effective Java 를 완독하고, Kotlin 을 상용으로 사용하는 개발자 입장에서 Effective Kotlin 글 중 새로운 내용, remind 할 필요 있는 부분, 핵심 내용 등만 추려 정리한 내용입니다. # 프로그래머들은 안정적이고 공식적인 API 를 쓰긴 원한다. 그 이유는.. API 변화는 개발자에게 코드 업데이트를 요구한다. API 변화/추가는 새로운 API 를 학습과 지식의 업데이트를 요구한다. # API 중 안정적이지 않은 부분을 문서에 잘 명시하는 것이 중요하다. # Semantic Versioning (SemVer) 는 Major.Minor.Patch 로 버전을 구분하는 버저닝을 이야기한다. Major 는 하위 호환되지 않는 API 변화가 있을 때, Minor 는 하위.. 2022. 4. 30.
반응형

티스토리툴바