아이템 52: mutable 컬렉션 사용을 고려하라
이펙티브 코틀린(효율성) 아이템 52: mutable 컬렉션 사용을 고려하라 immutable 컬렉션 보다 mutable 컬렉션이 좋은 점은 성능적인 측면에서 더 빠르다 컬렉션 복제는 처리 비용이 많이 든다 참조
1 min read
이펙티브 코틀린
52 posts
아이템 51: 성능이 중요한 부분에는 기본 자료형 배열을 사용하라
이펙티브 코틀린(효율성) 아이템 51: 성능이 중요한 부분에는 기본 자료형 배열을 사용하라 기본 자료형의 특징 가볍다 일반적인 객체와 다르게 추가적으로 포함되는것이 없기 때문 빠르다 값에 접근할 때 추가비용이 들지 않는다 일반적으로 array보다 list나 set을 사용하는 것이 좋다 하지만 기본 자료형 컬렉션을 굉장히
1 min read
아이템 50: 컬렉션 처리 단계 수를 제한하라
이펙티브 코틀린(효율성) 아이템 50: 컬렉션 처리 단계 수를 제한하라 전체 컬렉션에 대한 반복과 중간 컬렉션 생성이라는 비용이 발생함 이 비용은 적절한 컬렉션 처리 함수들을 활용해서 줄일 수 있다. 참조
1 min read
아이템 49: 하나 이상의 처리 단계를 가진 경우에는 시퀀스를 사용하라
이펙티브 코틀린(효율성) 아이템 49: 하나 이상의 처리 단계를 가진 경우에는 시퀀스를 사용하라 Iterable 과 Sequence 는 완전히 다른 목적으로 설계되어서 완전히 다른 형태로 동작한다 Sequence 는 지연 처리 된다 시퀀스 지연처리의 장점 자연스러운 처리 순서를 유지함 최소한만 연산함 무한 시컨스 형태로
1 min read
아이템 48: 더 이상 사용하지 않는 객체의 레퍼런스를 제거하라
이펙티브 코틀린(효율성) 아이템 48: 더 이상 사용하지 않는 객체의 레퍼런스를 제거하라 상태를 유지할 때는 메모리 관리를 염두에 두어야 한다는 것 코드를 작성할때는 메모리와 성능 뿐 아니라 가독성과 확장성을 항상 고려해야 한다 일반적으로는 가독성과 확장성이 더욱 중요하지만 라이브러리를 구현할 때는 메모리와 성능이 중요하
1 min read
아이템 47: 인라인 클래스의 사용을 고려하라
이펙티브 코틀린(효율성) 아이템 47: 인라인 클래스의 사용을 고려하라 inline 으로 만들수 있는것은 함수뿐만 아니다 하나의 값을 보유하는 객체도 inline 으로 만들수 있다 inline 클래스는 아래 상황에 많이 쓰인다 측정 단위를 표현할때 타입 오용으로 발생하는 문제를 막을때 인터페이스를 구현하는 인라인 클래스는
2 min read
아이템 46: 함수 타입 파라미터를 갖는 함수에 inline 한정자를 붙여라
이펙티브 코틀린(효율성) 아이템 46: 함수 타입 파라미터를 갖는 함수에 inline 한정자를 붙여라 inline 한정자의 역활은 컴파일 시점에 함수를 호출하는 부분을 함수의 본문으로 대체하는것 inline 한정자의 장점 타입 아규먼트에 reified 한정자를 붙여서 사용할수 있다 reified 한정자를 지정하면 타입 파
2 min read
아이템 45: 불필요한 객체 생성을 피하라
이펙티브 코틀린(효율성) 오늘날에는 코드 효율성을 관대 하게 바라본다 개발자가 비싸지고 메모리는 싸졌기 때문이다 장기적으로 효율성은 중요하다 아이템 45: 불필요한 객체 생성을 피하라 객체 생성에는 언제나 비용이 든다 객체를 wrap 하면 크게 3가지 비용이든다 객체는 더 많은 용량을 차지한다 요소가 캡슐화 되어 있다면
3 min read
아이템 44: 멤버 확장 함수의 사용을 피하라
이펙티브 코틀린(클래스설계) 아이템 44: 멤버 확장 함수의 사용을 피하라 확장함수는 첫 번째 아규먼트로 리시버를 받는 단순한 일반 함수로 컴파일된다 맴버 확장을 피해야 하는 이유 레퍼런스를 지원하지 않는다 암묵적으로 접근할때 두 리시버중에 어떤 리시버를 선택할지 혼동된다 확장 함수가 외부에 있는 다른 클래스를 리시버로
2 min read
아이템 43: API의 필수적이지 않는 부분을 확장 함수로 추출하라
이펙티브 코틀린(클래스설계) 아이템 43: API의 필수적이지 않는 부분을 확장 함수로 추출하라 클래스 메서드를 정의할때 멤버로 정의할 것인지 확장 함수로 정의할 것인지 결정해야 된다 맴버와 확장 방식의 차이점 따로 가져와서 사용해야 된다 일반적으로 확장은 다른 패키지에 위치한다 확장은 우리가 직접 멤버를 추가할 수 없는
2 min read
이펙티브 코틀린 아이템 42: compareTo의 규약을 지켜라
이펙티브 코틀린(클래스설계) 아이템 42: compareTo의 규약을 지켜라 compareTo는 Any에 있는 메소드가 아니라 부등식으로 변환되는 연산자이다. 비대칭적 동작: a≥b 이고 b≥a 라면 a==b이다. 연속적 동작: a≥b 이고 b≥c라면 a≥c이다. 코넥스적 동작(connex relation): a≥b 또는
2 min read
이펙티브 코틀린 아이템 41: hashCode의 규약을 지켜라
이펙티브 코틀린(클래스설계) 아이템 41: hashCode의 규약을 지켜라 해시 테이블 Map, Set : 컬렉션에 요소를 빠르게 추가하고 컬렉션에서 요소를 빠르게 추출해야한다고 할때 사용할 수 있는 자료구조 Map, Set은 중복 비허용 성능을 좋게 만드는 해결 방법 해시 테이블 해시 테이블은 각 요소에 숫자를 할당하는
3 min read
이펙티브 코틀린 아이템 40: equals 의 규약을 지켜라
이펙티브 코틀린(클래스설계) 아이템 40: equals 의 규약을 지켜라 동등성 코틀린에는 두 가지 종류의 동등성(equality)이 있다. 구조적 동등성(structural equality) : equals 메서드와 이를 기반으로 만들어진 == 연산자(!= 포함)로 확인하는 동등성이다. 레퍼런스적 동등성(referent
4 min read
이펙티브 코틀린 아이템 39: 태그 클래스보다는 클래스 계층을 사용하라
이펙티브 코틀린(클래스설계) 아이템 39: 태그 클래스보다는 클래스 계층을 사용하라 상수(constant) 모드를 가진 클래스를 많이 볼수 있다. 이러한 상수 모드를 태그(tag)라고 부르며 태크를 포함한 클래스를 태그 클래스라고 부른다. 태그 클래스는 서로다른 책임을 한 클래스에 태그로 넣는 문제를 가진다. 태그 클래스
5 min read
이펙티브 코틀린 아이템 38: 연산 또는 액션을 전달할 때는 인터페이스 대신 함수 타입을 사용하라
이펙티브 코틀린(클래스설계) 아이템 38: 연산 또는 액션을 전달할 때는 인터페이스 대신 함수 타입을 사용하라 대부분의 프로그래밍 언어에서는 함수 타입이 없다. 그래서 액션을 전달할때 메서드가 하나만 있는 인터페이스를 전달한다 이러한 인터페이스를 SAM(Single Abstract Method)이라 부른다. 파라미터 전달
3 min read
이펙티브 코틀린 아이템 37: 데이터 집합표현에 data 한정자를 사용하라
이펙티브 코틀린(클래스설계) 아이템 37: 데이터 집합표현에 data 한정자를 사용하라 떄로는 데이터를 한번에 전달해야 되는데 이럴때는 data 한정자를 사용해서 class를 만들면 좋다 toString equals와 hashcode copy : immutable 클래스를 만들때 유용하다. compoentN : 위치 기반
2 min read
이펙티브 코틀린 아이템 36: 상속보다는 컴포지션을 사용하라
이펙티브 코틀린(클래스설계) 아이템 36: 상속보다는 컴포지션을 사용하라 단순하게 코드 추출 또는 재사용을 위해 상속을 하려고 한다면, 조금 더 신중하게 생각해야 한다. 간단한 행위 재사용 상속의 단점 상속은 하나의 클래스만을 대상으로 할 수 있다. 상속을 사용해서 행위를 추출하다 보면 거대한 Base 클래스를 만들게 되
4 min read
이펙티브 코틀린 아이템 33: 생성자 대신 팩토리 함수를 사용하라
이펙티브 코틀린(객체생성) 아이템 33: 생성자 대신 팩토리 함수를 사용하라 생성자 역활을 대신해주는 함수를 팩토리 함수 팩토리 함수의 장점 함수의 이름을 붙일수 있다 함수가 원하는 타입을 리턴할 수 있다 호출될때 마다 새객체를 만들 필요가 없다 아직 존재하지 않는 객체를 리턴할 수 있다 객체 외부에 팩토리 함수를 만들면
5 min read
이펙티브 코틀린 아이템 34: 기본 생성자에 이름 있는 옵션 아규먼트를 사용하라
이펙티브 코틀린(객체생성) 아이템 34: 기본 생성자에 이름 있는 옵션 아규먼트를 사용하라 기본 생성자 : 객체를 정의하고 생성하는 방법을 지정할때 사용하는 가장 기본적인 방법 점층적 생성자 패턴(telescoping constructor pattern) 코틀린은 디폴트 아규먼트(default argument)를 사용할
3 min read
이펙티브 코틀린 아이템 35: 복잡한 객체를 생성하기 위한 DSL을 정의하라
이펙티브 코틀린(객체생성) 아이템 35: 복잡한 객체를 생성하기 위한 DSL을 정의하라 함수 타입의 몇가지 예 () Unit : 아규먼트를 갖지 않고, Unit을 리턴하는 함수 (Int) Unit : Int를 아규먼트로 받고, Unit을 리턴하는 함수 (Int) Int : Int를 아규먼트로 받고, Int를 리턴하는 함수
3 min read
이펙티브 코틀린 아이템 32: 추상화 규약을 지켜라
이펙티브 코틀린(추상화 설계) 아이템 32: 추상화 규약을 지켜라 규약은 개발자들의 단순한 합의 무언가를 할 수 있다는 것이 그것을 해도 괜찮다는 의미는 아니다. 상속된 규약 클래스를 상속하거나 다른 라이브러리의 인터페이스를 구현할 때는 규약을 반드시 지켜야 된다. 프로그램을 안정적으로 유지하고 싶으면 규약을 지켜야 된다
1 min read
이펙티브 코틀린 아이템 31: 문서로 규약을 정의하라
이펙티브 코틀린(추상화 설계) 아이템 31: 문서로 규약을 정의하라 함수가 무슨일을 하는지 명확하게 설명하고 싶다면 KDoc 주석을 붙혀주는것이 좋다. 일반적인 문제는 행위가 문서화 되지 않고 요소의 이름이 명확하지 않다면 이를 사용하는 사용자는 현재 구현에만 의존하게 된다. 이러한 문제는 예상되는 행위를 문서화만 잘해도
3 min read
이펙티브 코틀린 아이템 30: 요소의 가시성을 최소화하라
이펙티브 코틀린(추상화 설계) 아이템 30: 요소의 가시성을 최소화하라 API를 설계할때 간결한 API를 선호하는 이유 작은 인터페이스는 배우기 쉽고 유지하기 쉽다. 기능이 많은 클래스보다 작은 클래스이 이해하기 쉽다. 유지보수가 편하다. 변경을 가할떄는 기존것을 숨기는것 보다 새로운것을 만드는것이 편하다 그래서 가시성을
3 min read
이펙티브 코틀린 아이템 29: 외부 API를 랩(wrap)해서 사용하라
이펙티브 코틀린(추상화 설계) 아이템 29: 외부 API를 랩(wrap)해서 사용하라 랩(wrap) 해서 API를 사용할떄 장점 문제가 있다면 래버(wrapper)만 변경하면 되서 변화에 쉽게 대응 할수 있다. 프로젝트 스타일에 맞춰서 API의 형태를 조절할수 있다. 특정 라이브러리에서 문제가 발생하면 래퍼를 수정해서 다
2 min read
이펙티브 코틀린 아이템 28: API 안정성을 확인하라
이펙티브 코틀린(추상화 설계) 아이템 28: API 안정성을 확인하라 시멘틱 버저닝 MAJOR 버전: 호환되지 않는 수준의 API 변경 MINOR 버전: 이전 변경과 호환되는 기능을 추가 PATCH 버전: 간단한 버그 수정 어노테이션 @Experimental: 안정적이지 않음 @Deprecated: 더 이상 사용되지 않음
1 min read
이펙티브 코틀린 아이템 27: 변화로부터 코드를 보호하려면 추상화를 사용하라
이펙티브 코틀린(추상화 설계) 아이템 27: 변화로부터 코드를 보호하려면 추상화를 사용하라 상수 이름을 붙일 수 있다. 나중에 값을 쉽게 변경 가능하다. 함수 일반적인 알고리즘을 함수로 추출 하면 코드를 항상 기억해 두지 않아도 된다 함수의 단점 함수는 상태를 유지 하지 않는다. 함수 시그니처를 변경하면 프로그램 전체에
2 min read
이펙티브 코틀린 아이템 26: 함수 내부의 추상화 레벨을 통일하라
이펙티브 코틀린(추상화 설계) 추상화란 : 복잡한 자료, 모듈, 시스템 등으로 부터 핵심적인 개념 또는 기능을 간추려 내는것을 말한다. 추상화를 설계한다는 것은 단순하게 모듈 또는 라이브러리로 분리한다는 의미가 아니라 함수를 정의할 때는 그 구현을 함수 시그니처 뒤에 숨기게 되는데 이것이 바로 추상화다. 추상화의 목적 복
3 min read
이펙티브 코틀린 아이템 25: 공통 모듈을 추출해서 여러 플랫폼에서 재사용하라
이펙티브 코틀린(재사용성) 아이템 25: 공통 모듈을 추출해서 여러 플랫폼에서 재사용하라 코틀린은 멀티플랫폼을 지원해서 코드를 서로 다른 플랫폼에서 공유가 가능하다 공통 모듈을 추출해서 재사용하면 좋다. 참조
1 min read
이펙티브 코틀린 아이템 24: 제네렉 타입과 variance 한정자를 활용하라
이펙티브 코틀린(재사용성) 아이템 24: 제네렉 타입과 variance 한정자를 활용하라 위에 코드에서 파라미터 T는 variance 한정자(out 또는 in)이 없으므로 기본적으로 invariant(불공변성) 입니다. 제네릭 타입으로 들어가는 타입들이 서로 관련성이 없다는 의미 만약 어떠한 관련성을 원한다면 out 또는
3 min read
이펙티브 코틀린 아이템 23: 타입 파라미터의 섀도잉을 피하라
이펙티브 코틀린(재사용성) 아이템 23: 타입 파라미터의 섀도잉을 피하라 지역 파라미터가 외부 스코프에 있는 프로퍼티를 가린다. 이를 새도잉이라고 한다. 위와 같이 선언하면 타입 파라미터가 새도잉된다. 하지만 위처럼 독립적으로 동작합니다. 위처럼 선언해야 의도한 방식대로 동작할것입니다. 독립적으로 선언하고 싶으면 이름을
2 min read
이펙티브 코틀린 아이템 22: 일반적인 알고리즘을 구현할 때 제네릭을 사용하라
이펙티브 코틀린(재사용성) 아이템 22: 일반적인 알고리즘을 구현할 때 제네릭을 사용하라 타입 아규먼트를 사용하는 함수를 제네릭 함수라고 부른다.(예 stdlib에 있는 filter 함수) 타입 파라미터는 컴파일러에 타입과 관련된 정보를 제공하여 컴파일러가 타입을 정확하게 추측할수 있다. 제네릭 제한 타입 파라미터의 중요
1 min read
이펙티브 코틀린 아이템 21: 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라
이펙티브 코틀린(재사용성) 아이템 21: 일반적인 프로퍼티 패턴은 프로퍼티 위임으로 만들어라 property delegate 를 사용하는것이 property delegation 이라고 부른다. 코틀린에서 lazy 함수 제공 프로퍼티 위임을 사용하면 변화가 있을때 이를 감지하는 observable 패턴을 쉽게 만들수 있다.
5 min read
이펙티브 코틀린 아이템 20: 일반적인 알고리즘을 반복해서 구현하지 말라
이펙티브 코틀린(재사용성) 아이템 20: 일반적인 알고리즘을 반복해서 구현하지 말라 기존에 구현된 내용을 활용하면 장점 코드가 짧아진다. 코드 작성 속도가 빨라진다. 직접구현할때의 실수를 줄일수 있다. 제작자가 한번만 최적화하면 사용하는 모든곳에서 혜택을 받을수 있다. 표준라이브러리 살펴보기 stdlib는 확장함수를 활용
2 min read
이펙티브 코틀린 아이템 19: knowledge를 반복하지 말라
이펙티브 코틀린(재사용성) 재사용성 : 프로그램 언어의 핵심 특성 아이템 19: knowledge를 반복하지 말라 프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다. knowledge 를 반복하여 사용하지 말라 DRY 규칙, WET 안티패턴, SSOT(Singe Source of Truth)
3 min read
이펙티브 코틀린 아이템 18: 코딩 컨벤션 지켜라
이펙티브 코틀린(가독성) 아이템 18: 코딩 컨벤션 지켜라 문서를 보면 알수 있듯이 잘 정리된 코딩 컨벤션을 가지고 있다. 코틀린 커뮤니티에 속한 사람이면 이러한 코딩 컨벤션에 익숙해지는것이 좋다. 장점 어떠한 프로젝트도 쉽게 이해 할수 이다. 다른 외부 개발자도 프로젝트 코드를 쉽게 이해할수 있다. 다른 개발자도 코드
2 min read
이펙티브 코틀린 아이템 17: 이름 있는 아규먼트를 사용하라
이펙티브 코틀린(가독성) 아이템 17: 이름 있는 아규먼트를 사용하라 메소드의 Argument 용도가 분명하게 보이지 않을경우가 있다. 위처럼 joinToString에 | 값이 무엇을 뜻하는지 분명하지 않다. 코틀린에서는 이름있는 아규먼트를 지원한다. 물론 위와 같은 코드도 의미를 명확하게 알수 있다. 이름있는 아규먼트는
3 min read
이펙티브 코틀린 아이템 16: 프로퍼티는 동작이 아니라 상태를 나타내야 한다
이펙티브 코틀린(가독성) 아이템 16: 프로퍼티는 동작이 아니라 상태를 나타내야 한다 프로퍼티는 사용자 정의 게터와 세터를 가질수 있다. 파생 프로퍼티 (derrived property) : var을 사용해서 만든 읽고 쓸 수 있는 프로퍼티는 게터와 세터 정의가 가능, val 로 읽기 전용 프로퍼티를 만들때는 field가
2 min read
이펙티브 코틀린 아이템 15: 리시버를 명시적으로 참조하라
이펙티브 코틀린(가독성) 아이템 15: 리시버를 명시적으로 참조하라 무언가를 더 자세하기 설명하기 위해 명시적으로 긴코드를 사용할때가 있다. 대표적으로 함수와 프로퍼티 지역 또는 톱레벨 변수가 아닌 다른 리시버로부터 가지고 온다는것을 나타낼때가 있다. 예를 들면 클래스의 메서드라는것을 나타내기 위한 this가 있다. 리시
4 min read
이펙티브 코틀린 아이템 14: 변수 타입이 명확하지 않은 경우 확실하게 지정하라
이펙티브 코틀린(가독성) 아이템 14: 변수 타입이 명확하지 않은 경우 확실하게 지정하라 코틀린은 개발자가 타입을 지정하지 않아도 타입을 지정해서 넣어주는 굉장히 수준 높은 타입 추론 시스템을 가지고 있다. 이는 개발시간을 줄여주거나 코드를 줄여줘서 가독성이 크게 향상 된다. 하지만 유형이 명확하지 않을때 남용하지 말자.
2 min read
이펙티브 코틀린 아이템 13: Unit? 을 리턴하지 말라
이펙티브 코틀린(가독성) 아이템 13: Unit? 을 리턴하지 말라 Unit? 은 Unit 과 null을 반환할수 있다. 하지만 읽을때 오해의 소지가 있으며 예측하기 어려운 오류를 만들수 있다. Unit? 이 붙은 함수가 만들어지면 아래와 같은 코드가 나올수 있다. 이부분은 가독성 측면에서 이해하기 어렵다. 참조
1 min read
이펙티브 코틀린 아이템 12: 연산자 오버로드를 할 때는 의미에 맞게 사용하라
이펙티브 코틀린(가독성) 아이템 12: 연산자 오버로드를 할 때는 의미에 맞게 사용하라 연산자 오버로딩 할때는 항상 신중 해야 된다. 코틀린에서는 각 연산자의 의미는 항상 같게 유지된다. 그래서 오버로딩해서 연산자의 의미를 바꾸면 혼란스럽게 된다. 분명하지 않는 경우 Infix functions(두개의 변수 가운데 오는
2 min read
이펙티브 코틀린 아이템 11: 가독성을 목표로 설계하라
이펙티브 코틀린(가독성) 아이템 11: 가독성을 목표로 설계하라 코틀린은 간결성을 목표로 설계된 언어가 아니다 가독성을 항상 신경쓰자. 개발자가 코드를 작성하는데 1분 읽는데 10분 걸린다. 인식 부하 감소 가독성은 사람마다 다르게 느낄수 있다. 이해하기 쉬운지는 읽는 사람이 얼마나 많은 관용구(구조, 함수, 패턴)에 익
4 min read
이펙티브 코틀린 아이템 10: 단위 테스트를 만들어라
이펙티브 코틀린(안정성) 아이템 10: 단위 테스트를 만들어라 지금 까지 코드를 안전하게 만드는 방법에 대해 이야기 했다 코드를 안전하게 만드는 가장 좋은 방법은 다양한 테스트를 해보는것이다. 단위 테스트의 일반적인 내용 일반적인 유즈케이스(happy path) 일반적인 오류케이스 와 잠재적 문제 에지 케이스와 잘못된 아
2 min read
이펙티브 코틀린 아이템 9: use를 사용해 리소스를 닫아라
이펙티브 코틀린(안정성) 아이템 9: use를 사용해 리소스를 닫아라 Closeable를 구현하고 있는 클래스들을 처리 할때 try finally 를 사용해서 close 메소드를 호출 java의 try with resource 대신 use 와 Reader.useLines 확장 메소드를 제공한다. 참조
1 min read
이펙티브 코틀린 아이템 8: 적절하게 null을 처리하라
이펙티브 코틀린(안정성) 아이템 8: 적절하게 null을 처리하라 null 은 값이 부족하다(lack of value)는 것을 나타낸다. String.toIntOrNull() String을 Int로 적절하게 변환할수 없을때 null을 반환 Iterable<T .firstOrNull(() Boolean) 주어진 조건에 맞는
5 min read
이펙티브 코틀린 아이템 7: 결과 부족이 발생할 경우 null과 Failure를 사용하라
이펙티브 코틀린(안정성) 아이템 7: 결과 부족이 발생할 경우 null과 Failure를 사용하라 함수가 원하는 결과를 만들어 낼 수 없을때 이러한 상황을 처리하는 방법은 크게 두가지가 있다. null 또는 실패를 나타내는 sealed 클래스를 리턴한다. 예외를 throw 한다 예외는 예외 적인 상황이 발생했을때 사용하는
2 min read
이펙티브 코틀린 아이템 6: 사용자 정의 오류보다는 표준 오류를 사용하라
이펙티브 코틀린(안정성) 아이템 6: 사용자 정의 오류보다는 표준 오류를 사용하라 IllegalArgumentException 과 IllegalStateException 는 require 와 check 를 사용해 throw 할수 있는 예외 IndexOutOfBoundsException : 인덱스 파라미터 값이 범위를 벗어
1 min read
이펙티브 코틀린 아이템 5: 예외를 활용해 코드에 제한을 걸어라.
이펙티브 코틀린(안정성) 아이템 5: 예외를 활용해 코드에 제한을 걸어라 확실하게 어떤 형태로 동작해야 하는 코드가 있다면 예외를 활용해 제한을 거는것이 좋다. require 블록 : 아규먼트를 제한할 수 있다. check 블록 : 상태와 관련된 동작을 제한할 수 있다. assert 블록 : 어떤것이 true인지 확인할수
1 min read
이펙티브 코틀린 아이템 4: inferred 타입으로 리턴하지 말라
이펙티브 코틀린(안정성) 아이템 4: inferred 타입으로 리턴하지 말라 코틀린의 타입 추론은 가장 널리 알려진 코틀린의 특징이다. 타입추론을 사용할 때는 몇 가지 위험한 부분이 있다. 우선 할당 떄 inferred 타입은 정확하게 오른쪽에 있는 피연산자에 맞게 설정된다 절대로 슈퍼 클래스 또는 인터페이스로 설정되지
2 min read
이펙티브 코틀린 아이템 3: 최대한 플랫폼 타입을 사용하지 말라
이펙티브 코틀린(안정성) 아이템 3: 최대한 플랫폼 타입을 사용하지 말라 코틀린에서는 null safety 메커니즘을 사용해 NPE는 거의 찾아 보기 힘들다. 코틀린에서 자바 코드를 사용할때 @Nullable 어노테이션이 붙어 있으면 String?으로 변경하고 @NotNull 이면 String으로 선언하면 되는데 아무 어
2 min read
이펙티브 코틀린 아이템 2: 변수의 스코프를 최소화하라
이펙티브 코틀린(안정성) 아이템 2: 변수의 스코프를 최소화하라 상태를 정의할 때는 변수와 프로퍼티는 스코프를 최소화 하는것이 좋다. 프로퍼티보다 지역 변수를 사용하는것이 좋다. 최대한 좁은 스코프를 갖게 변수를 사용하자. 여러 프로퍼티를 한꺼번에 설정해야 하는 경우에는 구조분해 선언을 사용하는 것이 좋다. 스코프를 좁게
1 min read
이펙티브 코틀린 아이템 1: 가변성을 제한하라
이펙티브 코틀린(안정성) 아이템 1: 가변성을 제한하라 var 나 mutable 객체를 사용하면 상태를 가질수 있다. 상태를 가지는것은 양날의 검이다. 그래서 가변성을 제한하는것을 추천한다. 코틀린은 가변성을 제한하는것이 쉽게 만들어져 있다. 읽기 전용 프로퍼티(val) 가변 컬렉션과 읽기 전용 컬렉션 구분 데이터 클래스
3 min read