[Effective Kotlin] Item 27 : Use abstraction to protect code against changes

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

 

#
물 위를 걷는 것과 소프트웨어 개발하는 것은 쉽다.
만약 둘 다 얼어있다면..

 

Constant

 

 

Function

 

 

Class

#
class 는 상태를 가질 수 있다는 점에서 function 보다 좋다.
class 는 injection 이 가능하고, 따라서 test 도 유연해진다.

 

 

Interface

 

 

Next ID

 

 

Abstractions give freedom

#
Constant 추출하기
Function 으로 추출하기
Class 로 추출하기
Interface 로 class 감추기
Universal object 를 class 로 감추기

 

#
Generic type param 사용하기
Inner class 로 추출하기
Factory method 등으로 생성 제약하기

 

 

Problems with abstraction

#
추상화는 코드를 읽는 사람에게 복잡성을 추가한다.
그래서 무지성으로 추상화 하는 것은 기피된다.

 

 

Where is the balance?

#
Rule of thumb : 복잡도는 더 많은 자유를 주지만, 가독성을 해친다.
그래서 극단적인 것은 좋지 않다.

팀 크기, 팀 경험도, 프로젝트 사이즈, 기능 셋, Domain 지식 등을 놓고 잘 판단해야 한다.

 

#
프로젝트가 클수록 추상화는 더 요구된다.
DI 를 사용할 때는 생성에 대해 덜 신경쓴다.
Testing 는 추상화를 더 요구한다.
프로젝트가 작거나 실험적인 경우, 추상화를 할 필요가 별로 없다.

 

#
얼마나 자주 바뀔 것인가도 추상화 정도에 영향을 미친다.

 

 

Summary

 

끝