본문 바로가기

전체 글237

[이펙티브 코틀린] 아이템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.
[이펙티브 코틀린] 아이템17: 이름 있는 아규먼트를 사용하라 코드에서 아규먼트의 의미가 명확하지 않은 경우가 있다. 아래 코드에서 | 가 의미하는 바에 대하여 논란이 없을까?val text = (1..10).joinToString("|")만약 joinToString에 대하여 잘 알고 있다면, 구분자(seperator)를 의미한다는 것을 알 수 있겠지만모른다면, 이를 접두사(prefix)나 그 외 다른 것으로 생각 할 수도 있다. 따라서 명확하지 않을 수 있는 문제가 있다.이 문제를 해결하기 위해서는 아래은 방법으로 수정이 가능하다.// 아규먼트를 사용하는 방법val text = (1..10).joinToString(seperator = "|")// 변수를 사용하여 의미를 명확하게 하는 방법 val seperator = "|"val text = (1..10).joi.. 2025. 1. 8.
[이펙티브 코틀린] 아이템7: 결과 부족이 발생할 경우 null 또는 Failure를 사용하라 핵심 개념문제 상황우리가 구현한 함수가 항상 원하는 결과를 준다면 좋겠지만 그렇지 않은 경우도 있을 것이다.책에서 들었던 몇가지 예시는 아래와 같다.서버에서 데이터를 가져오려고 했지만 실패조건에 맞는 데이터를 찾지 못했거나 형식이 맞지 않음이 경우를 처리하는 방법은 두 가지가 있다.결과 부족을 처리하는 두 가지 방법1. null 또는 Failure 반환null: 결과가 없음을 나타내기 위해 간단하게 null을 리턴한다.Failure: sealed class를 사용해 실패 상태를 명확하게 표현한다.예를 들어 Success와 Failure 클래스를 사용하여 성공과 실패를 구분한다.장점: Failure를 사용하면 실패 원인을 담을 수 있고, when을 통해 명확하게 상태를 분리하여 처리할 수 있다.단점: nu.. 2024. 12. 18.
[이펙티브 코틀린] 아이템3: 최대한 플랫폼 타입을 사용하지 말라 코틀린의 주요 기능 중 하나는 Null-Safety 이다.코틀린은 Null-Safety 매커니즘으로 인해 NPE(Null Point Exception)을 찾아보기 힘들다.Java에서 Exception의 많은 부분을 차지한 NPE은 코틀린의 Null-Safety 를 만나 대부분 제거 되었다.하지만 Java, C와 같이 Null-Safety 가 지원되지 않는 언어와의 연결에서는 이러한 메커니즘으로 NPE를 완벽하게 보호할 수 없다.  1. 플랫폼 타입코틀린에서는 Java, C 에서 넘어온 데이터 타입을 특수하게 처리하는데, 이러한 타입을 플랫폼 타입이라고 한다.플랫폼 타입은 String! 처럼 타입 이름 뒤에 ! 기호를 붙여서 표기한다. 플랫폼 타입: 다른 프로그래밍 언어에서 전달되어 nullable인지 아.. 2024. 12. 11.

티스토리툴바