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

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

추상화 설계

위키피디아에서 추상화에 대한 정의는 다음과 같다.

컴퓨터 과학에서 추상화는 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것을 말한다.

쉽게 말하면 추상화라는 것은 어떤 형태든지 복잡한 것을 숨기기 위해 사용되는 단순한 형식을 의미한다. 가장 쉬운 예는 인터페이스다. 추상화는 다양한 형태로 될 수 있고 객체에서 무엇을 감추고 무엇을 노출해야하는지를 결정해야 한다.

프로그래밍에서의 추상화

프로그래밍에서의 추상화는 다양한 곳에서 하고 있다. 예는 다음과 같다.

• 숫자는 입력될 때 숫자라는 인터페이스로 입력되지만 실제로는 0과 1로 복잡하게 저장된다.
• 문자열은 문자로 입력되지만 UTF-8과 같은 복잡한 형태의 문자 집합으로 저장된다.
• 함수는 함수 시그니처로 선언되고 구체적인 것을 숨길 수 있다.
• 코틀린은 함수, 델리게이트, 클래스등으로 잘 활용하면 추상화를 할 수 있다.

추상화와 자동차

자동차와 비유하여 추상화에 대해서 설명해준다. 자세한 내용은 책을 참고하길 바란다.

프로그래밍에서 추상화를 하는 목적은 다음과 같다.

• 복잡성을 숨기기 위해
• 코드를 체계화하기 위해
• 만드는 사람에게 변화의 자유를 주기 위해

함수 내부의 추상화 레벨을 통일하라

컴퓨터는 굉장히 복잡한 장치다. 이 장치는 애플리케이션, 프로그래밍 언어, 어셈블러, 하드웨어, 물리장치 순으로 사람과 장치에 가까운 순으로 계층을 분리할 수 있다. 개발자는 다행히도 각 계층에 대해서 다 알 필요없고 이 계층에서 선택적으로 알아서 컴퓨터를 제어하면 된다.

추상화 레벨

레벨이 높으면 물리장치로부터 멀어지고 프로세서로부터 멀어진다고 표현한다. 높은 레벨일수록 세부적인 내용을 고려할 필요는 없다. 무조건 높은 레벨이 높은 것은 아니다. 예를 들어 자바 같은 경우 높은 레벨에 포함된 언어인데 메모리를 GC가 관리해주기 때문에 신경을 안써도 되지만 그만큼 최적화가 어렵다.

추상화 레벨 통일

컴퓨터 과학이 높은 레벨과 낮은 레벨을 확실하게 구분하는 것처럼 함수도 높은 레벨과 낮은 레벨을 구분해서 사용해야한다. 이를 추상화 레벨 통일 원칙이라고 한다.

이를 간단하게 설명하면 함수 하나에 50줄이 되는 로직이 있으면 이를 각각의 단계별로 나워서 10줄씩 5개로 되는 함수로 나눠서 만들라는 의미다. 여기서 각 5개의 함수들이 낮은 레벨의 함수들이 각 함수들이 합쳐져서 하나의 로직을 구성하는 것이 높은 레벨의 함수가 된다.

이렇게 함수를 구성했을 때 좋은 점은 각 함수가 하는 일이 명확하게 나눠지면 변경이 필요할 때 수정해야하는 포인트가 적어지고 테스트도 하기 쉬워진다.

프로그램 아키텍처의 추상 레벨

이 절에서 이야기하고 싶은 것은 함수뿐만 아니라 모듈 시스템을 설계할 때도 레벨을 나눌 수 있음을 강조한다. 예를 들어, 애플리케이션의 입력과 출력은 낮은 레벨의 모듈이고 비즈니스 로직을 나타내는 부분은 높은 레벨의 모듈이다.

정리

• 추상화는 구체적인 내용을 숨김으로써 사용하는 곳과 사용되는 곳에 대해 상호 운영성과 플랫폼 독립성을 얻게 한다.
• 각 레벨은 작고 최소한의 책임만 갖게하는 것이 좋다. 그래야 이해가 쉽다.
• 레벨을 구분하는 기준은 구체적인 동작, 프로세서, 입출력과 가까울 수록 낮다.

변화로부터 코드를 보호하려면 추상화를 사용하라

추상화를 통해 실질적인 코드를 숨기는 이유는 실질적인 코드를 변경되는 것에 대해 사용되는 쪽에 영향을 주지 않으면서 쉽게 변경하기 위함에 있다. 다음 3가지 예를 살펴보자.

상수

상수를 리터럴 그대로 선언해놓고 사용하면 어떤 의미를 가지고 있는지 다른 개발자가 파악하기 어렵다. 이런 경우에는 의미가 변색되지 않게 사용하려면 상수로 선언하고 사용해야한다.

함수

함수를 선언할 때, 특정 상황에 대해서 함수를 하나로 선언할 수도 있지만 이를 좀 더 보편적인 상황에 맞춰 이름을 사용하는 것이 좋다.

자세한 예제는 책을 참고하길 바란다.

클래스

클래스는 함수보다 좀 더 강력하게 추상화할 수 있다. 그 이유는 상태를 저장하고 있을 수 있기 때문이다. 좀 더 추상화하기 위해서는 인터페이스를 사용해야 한다.

인터페이스

코틀린 표준 라이브러리는 대부분 인터페이스로 구현되어 있다. 인페이스로 추상화한다는 의미는 클래스를 인터페이스 뒤에 숨긴다는 의미다. 이를 통해 얻을 수 있는 실제 구현되는 내용에 따라 다양한 방식으로 결과를 낼 수 있다.

자세한 예제는 책을 참고하길 바란다.

추상화가 주는 자유

책에서 제안하는 추상화 방법은 다음과 같다.

• 상수로 추출한다.
• 동작을 함수로 래핑한다.
• 함수를 클래스로 래핑하낟.
• 인터페이스 뒤에 클래스를 숨긴다.
• 보편적인 객체를 특수한 객체로 래핑한다.

이를 구현하기 위한 도구는 다음과 같다.

• 제네릭 타입 파라미터를 사용한다.
• 내부 클래스를 추출한다.
• 생성을 제한한다.

추상화의 문제

추상화를 하면 다른 사람이 해당 코드를 이해하는데 시간이 걸린다. 따라서 극단적으로 모든 것을 추상화해서는 안된다. 추상화는 거의 무한하게 할 수 있지만 어느 순간되면 실이 더 많을 수도 있다.

어떻게 균형을 맞춰야 할까?

추상화에 대해 영향이 가는 요소들은 다음과 같다.

• 팀의 크기
• 팀의 경험
• 프로젝트의 크기
• 특징 세트
• 도메인 지식

책에서는 몇가지 규칙을 정리해줬는데 이는 책을 통해 확인하길 바란다.

정리

추상화는 코드를 변경해야할 때 도움이 되어야 한다. 추상화에 대한 장점과 단점을 모두 이해하고 그 균형을 잘 찾아야 한다.

API 안정성을 확인하라

모든 것은 표준적인 API를 만들어서 사용하는 것이 좋다. 책의 내용을 짧게 요약하면 다음과 같다.

• API가 격변하면 사용자가 이를 모두 수정해야한다.
• 새로운 API에 대해서 사용자가 숙지해야한다.

API는 한번에 안정적이게 만들 수 없기 때문에 버저닝을 사용하는 것이 좋다. 일반적으로 사용하는 버저닝은 다음과 같다.

• MAJOR : 호환되지 않는 수준의 API 변경
• MINOR : 이전 변경과 호환되는 기능을 추가
• PATCH : 간단한 버그 수정

추가적으로 코틀리넹서는 안정적이지 않은 API에 대해서 @Experiamental 같은 애노테이션을 사용해서 사용자에게 알려주고 있다.

정리

API를 만드는 사람은 사용하는 사용자의 입장을 고려해서 수정이 이루어져야 한다. 그리고 사용자에게 API의 안정성에 대해서 적절하게 알려줘야 한다.

외부 API를 랩(wrap)해서 사용하라

코드에서 직접적으로 해당 API에 대해서 사용하지말고 한번 wrap해서 사용하는 것이 좋다. 장점으로는 다음과 같은 내용이 있다.

• 문제가 있으면 wrap한 부분만 수정하면 된다.
• 프로젝트 스타일에 맞춰서 API의 형태를 조정할 수 있다.
• 라이브러리를 쉽게 변경할 수 있다.
• 필요한 경우 쉽게 동작을 추가하거나 수정할 수 있다.

단점은 다음과 같다.

• 래퍼를 따로 정의해야한다.
• 다른 개발자들이 래퍼를 확인해야한다.
• 해당 프로젝트에 대해서만 유효하므로 커뮤니티에 질문할 수 없다.

요소의 가시성을 최소화하라

코틀린의 가시성 한정자에 대한 설명을 해준다. 자세한 내용은 책을 참고하길 바란다.

문서로 규약을 정의하라

적절한 주석 사용에 대한 설명을 해준다. 자세한 내용은 책을 참고하길 바란다.

추상화 규약을 지켜라

코틀린에서 주어진 규약을 잘키고 그런 상황이 아니라면 문서화를 하라는 내용이다. 자세한 내용은 책을 참고하길 바란다.