Study OR Book9 [이펙티브 코틀린] 아이템46: 함수 타입 파라미터를 갖는 함수에 inline 한정자를 붙여라 1. 고차 함수다른 함수를 인자로 받거나 함수를 반환하는 함수코틀린에서 람다나 함수 참조를 사용해 함수를 값으로 표현할 수 있음 2. 고차 함수와 inline 의 필요성코틀린에서는 람다 표현식이 객체로 변환되므로 성능 및 메모리 측면에서 오버헤드 발생할 수 있음이를 최적화하기 위해 inline 키워드를 사용하면 성능이 향상 3. 인라인 함수 (inline)컴파일 시점에 함수의 호출 코드가 해당 위치로 직접 복사되는 함수이를 통해 함수 호출 오버헤드를 줄이고, 람다 객체 생성을 방지하여 성능을 최적화 할 수 있음 noInlineTest는 객체를 생성inlineTest는 객체를 생성하지 않고 코드가 직접 삽입되어 실행 속도가 훨씬 빠름 4. reified 키워드기본적으로 JVM의 제네릭은 타입 소거(Type.. 2025. 2. 20. [이펙티브 코틀린] 아이템43: API의 필수적이지 않는 부분을 확장 함수로 추출하라 클래스의 메서드를 정의 할 때, 메서드를 아래 중 어떤 것으로 정의할 것인지 결정해야 한다.멤버로 정의할 것인가?확장 함수로 정의할 것인가? 1) 멤버 함수 (Member Function)클래스 내부에서 직접 정의된 메서드해당 클래스에 종속됨클래스 인스턴스를 통해 호출됨class Workshop(/*...*/) { // ... fun makeEvent(data: DateTime): Event = // ... val permalink get() = "/workshop/$name"} 2) 확장 함수 (Extension Function)기존 클래스의 기능을 확장하는 함수클래스 외부에서 정의됨클래스 내부 멤버처럼 사용할 수 있지만, 실제로는 첫 번째 매개변수로 리시버 객체를 받는.. 2025. 2. 18. [이펙티브 코틀린] 아이템40: equals의 규약을 지켜라 코틀린의 Any에는 다음과 같이 잘 설정된 규약들을 가진 메서드들이 있다.equalshashCodetoString'아이템 32: 추상화 규약을 지켜라' 에서 자깐 hashCode와 equals가 언급되었다.이번엔 지난번에 언급된 equals에 대하여 더 깊이 그리고 많이 언급하고 있다. 동등성코틀린에는 두 가지 종류의 동등성이 있다. 1) 구조적 동등성equals 메서드와 이를 기반으로 만들어진 == 또는 != 연산자로 확인하는 동등성이다.a가 nullable이 아니라면 a == b a.equals(b)로 변환되고, a가 nullable이라면 a?.equals(b) ?: (b === null)로 변환된다. 2) 레퍼런스적 동등성=== 또는 !== 연산자로 확인하는 동등성이다.두 피연산자가 같은 객체를 가.. 2025. 2. 10. [이펙티브 코틀린] 아이템32: 추상화 규약을 지켜라 본 챕터는 '규약은 개발자들의 단순한 합의' 라는 내용으로 시작한다.규약이란 것은 한쪽이 위반할 수도 있으며, 기술적으로는 모든 부분에서 규약 위반이 발생할 수도 있다. 규약을 위반한 코드는 시한 폭탄을 설치한 것과 같으며, 코드가 작동을 멈췄을 때 문제가 된다. 상속된 규약규약을 반드시 지켜야 하는 경우는 1) 클래스 상속, 2) 다른 라이브러리의 인터페이스 구현을 하게되는 시점이다. 예를 들어 모든 클래스는 equals, hashCode 메서드를 가진 Any 클래스를 상속 받는데, 이러한 메서드는 지켜야하는 규약을 가지고 있다.만약 hashCode가 제대로 구현되지 않으면, HashSet과 함께 사용할 때 제대로 동작하지 않는다. 아래 코드에서 보여주는 바는 equals가 제대로 구현되지 않았을 경우.. 2025. 2. 3. [이펙티브 코틀린] 아이템29: 외부 API를 랩(wrap)해서 사용하라 이번 챕터는 코드와 관련된 기술적인 내용 보다는 좋은 코드에 대한 가이드가 간략하게 나와 있는 것 같다. API가 불안정한 이유에는 여러가지가 있을 것이고, 이때 불안정한 API를 과도하게 사용하는 것은 위험한 일이다.만약 이러한 경우 불가피하게 API를 활용해야 한다면, 최대한 API를 로직과 분리시키는 것이 좋다.많은 프로젝트가 잠재적으로 불안정하다고 판단되는 외부 라이브러리 API를 랩(wrap)해서 사용한다. 랩해서 사용 했을 때의 장점 1. 문제가 있다면 래퍼(wrapper)만 변경하면 되므로, API 변경에 쉽게 대응 가능하다. (캡슐화하여 사용하기 때문)2. 프로젝트의 스타일에 맞춰 API 형태 조정이 가능하다. (직렬화 등을 래퍼에서 처리 가능)3. 특정 라이브러리에 문제 발생 시 래퍼.. 2025. 1. 21. [이펙티브 코틀린] 아이템19: knowledge를 반복하여 사용하지 말라 이 책의 저자가 생각하는 프로그래밍의 가장 큰 규칙은 아래와 같다.프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다. 이번 챕터의 제목인 'knowledge를 반복하여 사용하지 말라'는 위의 내용을 저자의 방식으로 표현한 것이다.위 규칙은 DRY 규칙, WET 안티패턴, SSOT 등으로도 불린다.위 규칙을 확실하게 적용하려면, 언제 왜 이 이야기가 나오는지 이해해야한다. knowledge프로그래밍에서 knowledge 는 넓은 의미로 '의도적 정보'를 뜻한다.프로젝트를 진행할 때 정의한 모든 것이 knowledge가 될 수 있다. 예를 들어 알고리즘의 작동 방식, UI 형태, 우리가 원하는 결과 등 모두 의도적 정보이자 knowledge 이다. 우리 프로그램에서 중요한 kn.. 2025. 1. 15. 이전 1 2 다음
