[TIL] 이펙티브 코틀린 - 3 장

이 글은 이펙티브 코틀린 3장을 보면서 배운 것에 대해서 요약합니다. 코드 예제, 자세한 설명은 생략되어 있기 때문에 이펙티브 코틀린을 구입해서 보시는 것을 적극적으로 추천합니다.

재사용성

API, 프레임워크, 라이브러리등을 통해 이미 만들어진 기능을 다시 활용하는 것을 재사용성이라고 한다. 재사용성은 공통적인 부분을 뽑아서 만들었기 때문에 활용하기는 좋지만 공통적인 부분을 수정했을 때 활용하는 곳에서 모두 문제가 발생할 수 있다. 이런 것을 고려하면서 재사용성을 활용하는 것은 어려운 일이다. 이 장에서는 재사용성을 극대화하기 위해서 어떻게 연습해야하고 코드를 개선하는지에 대해서 살펴본다.

knowlege를 반복하여 사용하지 말라

책의 저자가 생각하는 프로그래밍의 가장 큰 규칙은 다음과 같다.

프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다.

이 이야기의 핵심은 이미 검증된 코드를 여러번 복사해서 사용하여 시간을 낭비하지 말라는 의미다.

knowlege

저자가 말하는 knowlege는 의도적인 정보를 의미한다. 의도적인 정보라는 것은 프로젝트를 진행할 때 정의한 모든 것을 의미한다. 예를 들어, 알고리즘의 작동 방식, UI의 형태, 우리가 원하는 결과등이 있다. 이는 코드, 설정, 템플릿으로 표현이 된다.

knowledge에서 중요한 두가지를 뽑는다면 다음과 같다.

• 로직
• 공통 알고리즘

자세한 설명은 책을 참고하길 바란다.

모든 것은 변화한다

우리가 만드는 프로젝트는 항상 변화하고 있고 변화하고 있는 대표적인 이유는 다음과 같다.

• 회사 사용자의 요구 또는 습관을 더 많이 알게 되었다.
• 디자인 표준이 변화했다.
• 플랫폼, 라이브러리, 도구 등이 변화해서 이에 대응해야 한다.

위와 같은 이유로 프로젝트는 변화하기 때문에 코드가 변경되어야 한다. 하지만 똑같은 knowlege가 여러 곳에 분산되어 있다면 모두 찾아서 변경해야하고 거기서 어떤 문제가 발생할지 모른다. 책에 아래와 같은 문구가 있다.

knowlege 반복은 프로젝트의 확정성(scable)을 막고, 쉽게 깨지게(fragile) 만듭니다.

개발자는 knowlege 반복을 줄여야하고 여러가지 기능과 도구를 통해서 이를 해결할 수 있다.

언제 코드를 반복해도 될까?

코드가 반복을 항상 배제하는 것은 아니다. 반복처럼 보이지만 실제로는 다른 knowlege를 나타내면 공통으로 추출하면 안된다. 자세한 이야기는 책에 적혀있지만 간단하게 판단한다면 “함께 변경될 가능성이 높은가? 따로 변경될 가능성이 높은가?”라는 질문을 던져보면 된다.

단일 책임 원칙

잘못된 코드 추출로부터 우리를 보호할 수 있는 규칙은 SRP다. 단일 책임 원칙이란 “클래스를 변경하는 이유는 단 한가지여야 한다.” 라는 의미른 가지는 SOLID 원칙 중에 하나다.

책에서는 자세하게 설명해주는데 자세한 설명은 책을 통해 보면 된다. 내가 이해한 핵심은 다음과 같다.

• 사용하는 액터(변화를 만들어 내는 존재, 책에서는 부서 단위로 보고 있다.)마다 클래스 변경 이유가 다르다.
• 공통적으로 사용해서 변경해야하는 것이 아니라면 헬퍼 함수를 사용해라.
• 코틀린의 확장함수를 통해서 헬퍼 함수를 간단하게 작성해라.

정리

공통 knowlege가 있다면 이를 추출해서 변화에 대비해야 한다.

일반적인 알고리즘을 반복해서 구현하지 말라

일반적으로 사용되는 알고리즘(sort 등)은 stdlib에 구현되어 있으니 표준 라이브러리를 사용하라는 내용이다.

만약 표준 라이브러리에는 존재하지 않는 알고리즘이라면 직접 만들어야하는 직접 만들 때는 확장함수를 통해 만드는 것을 추천한다. 확장함수는 추천하는 이유는 다음과 같다.

• 구체적인 타입이 있는 객체에만 사용을 제한할 수 있다.
• 수정할 객체를 아규먼트로 전달받아 사용하는 것보다 확장 리시버로 사용하는 것이 가독성이 더 좋다.
• . 을 통해서 함수를 찾을 수 있기 때문에 찾기가 더 쉽다.

정리

• 일반적인 알고리즘은 표준 라이브러리를 찾아봐라
• 없는 것은 확장함수를 통해 만들어라

일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라

프로퍼티를 위임한다는 것은 다른 객체로부터 프로퍼티를 전달 받아서 사용하는 것을 의미한다.

코틀린에서는 이를 쉽게 구현할 수 있다. 다음은 lazy 프로퍼티 패턴을 쉽게 구현한 lazy 함수다.

val value by lazy { createValue() }

이 패턴은 프로퍼티를 처음 사용할 때 init이 되는 것을 유의하도록 하자.

코틀린에서는 프로퍼티 위임을 사용하면 observable 패턴을 쉽게 구현할 수 있다. 다음은 그 예제다.

var items: List<Item> by Delegates.observable(listOf()) { _, _, _ ->
  notifyDataSetChanged()
}

프로퍼티 위임 메커니즘은 다음과 같은 패턴에 사용할 수 있다.

• 뷰, 리소스 바인딩
• 의존성 주입,
• 데이터 바인딩

책에서는 어떻게 프로퍼티 위임을 구현하는지 자세하게 설명이 되어있다. 이 내용은 생략하기로 하겠다.

다음의 프로퍼티 델리게이터를 알아두면 좋다고 한다.

• lazy
• Delegates.observable
• Delegates.vetoable
• Delegates.notNull

일반적인 알고리즘을 구현할 때 제네릭을 사용하라

코틀린의 콜렉션 함수처럼 타입 파라미터를 제네릭으로 선언하고 사용하라는 의미다.

타입 파리미터의 섀도잉을 피하라

클래스의 프로퍼티와 함수의 파라미터가 같은 경우를 섀도잉이라고 한다. 특히 타입 파라미터로 제네릭을 사용하는 경우 섀도잉을 하면 오류를 찾기가 어렵기 때문에 더 주의해야한다.

제네릭 타입과 variance 한정자를 활용하라

• ToDo

공통 모듈을 추출해서 여러 플랫폼에서 재사용하라

코틀린이 여러가지 플랫폼(native, jvm, android, javascript 등) 제공해주기 때문에 공통 모듈을 잘 추출해서 여러 분야해서 활용해 사용하라는 내용이다.