이펙티브 코틀린 - 2부 3장

3장 재사용성

누군가가 이러한 것을 한 번 만들어 놓으면, 필요한 때 이를 활용할 수 있는 것이다. 이것이 바로 프로그래밍 언어의 핵심 특징이라고 할 수 있는 재사용성이다.
장기적으로 코드를 개선하는 데 도움이 되는 여러 가지 방법을 설명

아이템 19: knowledge를 반복하여 사용하지 말라

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

 
knowledge를 크게 두 가지 뽑는다면,
1. 로직
2. 공통 알고리즘
비즈니스 로직은 시간이 지나면서 계혹해서 변하지만, 공통 알고리즘은 한 번 정의된 이후에는 크게 변하지 않는다.
 
프로그래밍에서 유일하게 유지되는 것은 '변화한다는 속성'
기술뿐만 아니라 언어도 빠른 속도로 변화한다.
변화는 우리가 예상하지 못한 곳에서 일어난다.
슬랙은 글리치라는 온라인게임이었다. 게임은 운영 중단됐지만, 소비자는 이 게임의 커뮤니케이션 방식을 굉장히 마음에 들어했다. 그래서 현재의 슬랙으로 변화한 것이다.
(사내에서 사용되는 null 이라는 서비스는 최초에 개발지식공유 서비스에서 비공개 커뮤니티의 성격으로 변했다.)
변화할 때 가장 큰 적은 knowledge가 반복되어 있는 부분
knowledge 반복은 프로젝트의 확장성을 막고, 쉽게 깨지게 만든다.
 
두 코드가 같은 knowledge를 나타내는지 다른 knowledge를 나타내는지 함께 변경될 가능성이 높은지 따로 변경될 가능성이 높은지에 따라서 결정할 수 있다.
코드를 추출하는 이유는 변경을 쉽게 만들기 위함이므로, 이 질문은 가장 근본적인 질문이라고 할 수 있다.
잘못된 코드 추출로부터 우리를 보호할 수 있는 규칙 - 단일책임원칙
 

• 서로 다른 곳에서 사용하는 knowledge는 독립적으로 변경할 가능성이 많다. 비슷한 처리를 해도 다른 knowledge로 취급하는 것이 좋다.
• 다른 knowledge는 분리해 두는 것이 좋다. 그렇지 않으면 재사용의 유혹이 발생할 수 있다.

 

아이템 20: 일반적인 알고리즘을 반복해서 구현하지 말라

이미 있는 것을 활용하면, 단순하게 코드가 짧아진다는 것 이외에도 다양한 장점이 있다.

• 코드 작성 속도가 빨라진다.
• 구현을 따로 읽지 않아도, 함수의 이름 등만 보고도 확실하게 알 수 있다.
• 직접구현할 때 발생할 수 있는 실수를 줄일 수 있다.
• 제작자들이 한 번만 최적화 하면 혜택을 받을 수 있다.

코틀린에서는 자바빈 패턴을 더 이상 찾아볼 수 없다.
팩토리 메서드를 활용하거나 기본 생성자를 활요하는 것이 좋다.
 
상황에 따라서 표준 라이브러리에 없는 알고리즘이 필요할 수 있다.
범용 유틸리티 함수로 정의하는 것이 좋다.
동일한 결과를 얻는 함수를 여러 번 만드는 것은 잘못된 일이다. 모든 함수는 테스트되어야 하고, 기억되어야 하며, 유지보수 되어야 한다.
많이 사용되는 알고리즘을 추출하는 방법으로는 톱레벨 함수, 프로퍼티 위임, 클래스 등이 있다.

• 확장함수의 장점
• 함수는 상태를 유지하지 않으므로, 행위를 나타내기 좋다.
• 톱 레벨 함수와 비교해서 확장 함수는 구체적인 타입이 있는 객체에만 사용을 제한할 수 있다.
• 수정할 객체를 아규먼트로 전달받아 사용하는 것보다 확장 리시버로 사용한느 것이 가독성 측면에서 좋다.
• 확장 함수는 객체에 정의한 함수보다 객체를 사용할 때, 자동 완성 기능 등으로 제안이 이루어지므로 쉽게 찾을 수 있다.

 

아이템 21: 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라

코틀린의 stdlib는 lazy 프로퍼티 패턴을 쉽게 구현할 수 있게 lazy 함수를 제공한다.
프로퍼티 위임을 사용하면 변화가 있을 때 이를 감지하는 observable 패턴을 쉽게 만들 수 있다.
프로퍼티 위임의 좋은 예 - 뷰, 리소스 바인딩, 의존성 주입, 데이터 바인딩
 
자바 등에서는 어노테이션을 많이 활용해야 한다.
코틀린은 프로퍼티 위임을 사용해서 간단하고 type-safe하게 구현할 수 있다.
 
프로퍼티 위임은 다른 객체의 메서드를 활용해서 프로퍼티의 접근자를 만드는 방식이다.
메서드 이름이 중요, 게터 - getValue, 세터 - setValue
객체를 만든 뒤에는 by 키워드를 사용해서 정의한 클래스와 연결
 
컨텍스트(this)와 프로퍼티 레퍼런스의 경계도 함께 사용하는 형태로 바뀐다.
 
코틀린 개발자라면 프로퍼티 위임이라는 강력한 도구와 관련된 내용을 잘 알고 있어야 한다.

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

컴파일 과정에서 최종적으로 제네릭 타입정보는 사라지지만, 개발 중에는 특정 타입을 사용하게 강제할 수 있다.
코틀린은 강력한 제네릭 기능을 갖고 있지만, 조금 복잡해서 이해하기 어렵다.
 
타입 파라미터를 사용해서 일반적으로 type-safe 제네릭 알고리즘과 제네릭 객체를 구현
타입 파라미터는 구체 자료형의 서브타입을 제한할 수 있다.
특정 자료형이 제공하는 메서드를 안전하게 사용할 수 있다.

아이템 23: 타입 파라미터의 섀도잉을 피하라

프로퍼티와 파라미터가 같은 이름을 가질 수 있다.
지역 파라미터가 외부 스코프에 있는 프로퍼티를 가린다. 이를 새도잉이라 한다.
타입 파라미터를 사용해서 다른 타입 파라미터에 제한을 줄 수 있다.
 

아이템 24: 제네릭 타입과 variance 한정자를 활용하라

variance 한정자가 없으면 기본적으로 invariant(불공변성)이다.
invariant라는 것은 제네릭 타입으로 마들어지는 타입들이 서로 관련성이 없다는 것을 의미한다.
out은 타입 파라미터를 covariant(공변성)으로 만든다. 이는 A가 B의 서브타입일 때, Cup<A>가 Cup<B>의 서브타입이라는 의미다.
in 한정자는 타입 파라미터를 contravariant(반변성)으로 만든다. 이는 A가 B의 서브타입일 때 Cup<A>가 Cup<B>의 슈퍼타입이라는 것을 의미한다.
 
함수 타입
코틀린의 함수 타입의 모든 파라미터 타입은 contravariant(in 한정자)이다. 또한 모든 리턴 타입은 covariant(out 한정자)이다.
contravariant를 가진 List variance 한정자가 붙지 않은 MutableList와 다르다.
 
variance 한정자의 안정성
자바의 배열은 covariant이다.
numbers를 Object[]로 캐스팅해도 구조 내부에서 실질적인 타입이 바뀌는 것은 아니다.
코틀린은 이러한 결함을 해결하기 위해서 Array를 invariant로 만들었다.
(런타임이 아닌 컴파일 타임에서 오류를 낼 수 있는 듯)
public in 한정자 위치에 convariant 타입 파라미터(out 한정자)가 오는 것을 금지하여 이런 상황을 막는다.
(public 함수의 파라미터 타입은 in 한정자)
위 상황에서 public in을 private으로 제한하면 오류가 발생하지 않는다.
객체 내부에서 업캐스트 객체에 covariant(out 한정자)를 사용할 수 없기 때문이다.
covariant는 public out 한정자 위치에서도 안전하므로 따로 제한되지 않는다. 이러한 안정성의 이유로 생성되거나 노출되는 타입에만 covariant를 사용한다.
코틀린은 contravariant 타입 파라미터를 public out 한정자 위치에 사용하는 것을 금지하고 있다.
위 상황에서 public out을 private로 제한하면 문제가 없다.
 
variance 한정자의 위치
MutableList는 in 한정자를 포함하면, 요소를 리턴할 수 없으므로 in 한정자를 붙이지 않는다.

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

소스코드를 공유할 수 있다면, 큰 이득이 발생한다.
 
코틀린이 자바스크립트로 컴파일될 수 있다.
 
iOS의 경우 LLVM을 사용하여 네이티브 코드로 컴파일 할 수 있는 코틀린/네이티브를 사용하면 Objective-C 프레임워크로 변환할 수 있다.
 

• 코틀린/JVM을 사용한 백엔드 - 스프링, Ktor 등
• 코틀린/JS를 사용한 웹사이트 개발 - 리액트 등
• 코틀린/JVM을 사용한 안드로이드 개발 - 안드로이드 SDK 등
• 코틀린/네이티브를 통해 Objective-C/스위프트로 iOS 프레임워크 개발
• 코틀린/JVM을 사용한 데스크톱 개발 - TornadoFX 등
• 코틀린/네이티브를 사용한 라즈베리파이, 리눅스, macOS 프로그램 개발

코드를 한 번만 작성해서 공통논리 또는 공통 알고리즘을 재사용할 수 있게 해 주는 강력한 도구라고 할 수 있다.