본문 바로가기

Reading Record

ㅤㅤㅤㅤㅤ
By crud
[이펙티브 코틀린] Item 34. 기본 생성자에 이름 있는 옵션 아규먼트를 사용하라 아이템 34 기본 생성자에 이름 있는 옵션 아규먼트를 사용하라 점층적 생성자 패턴 점층적 생성자 패턴은 프로퍼티별 디폴트 값을 가질 경우 파라미터별로 생성자를 각각 만드는 패턴이다. class Foo{ val size:Int val length: Int constructor(size: Int,length: Int){ this.size=size this.length = length } constructor(size:Int): this(size,0) } 코틀린에서는 디폴트 아규먼트를 지정할 수 있기 때문에 해당 코드는 무의미하다. 이름 있는 아규먼트를 활용해서 명시적으로 이름을 붙여주면, 의미가 훨씬 명확하다. 빌더 패턴 자바에서는 이름 있는 파라미터와 디폴트 아규먼트를 사용할 수 없어, 빌더패턴을 사용한다.. Reading Record/이펙티브 코틀린 2022. 6. 7.
ㅤㅤㅤㅤㅤ
By crud
[이펙티브 코틀린] Item 33. 생성자 대신 팩토리 함수를 사용하라 아이템 33 생성자 대신 팩토리 함수를 사용하라 팩토리 함수의 장점 생성자와 다르게 함수에 이름을 붙일 수 있다. 생성되는 방법과 아규먼트로 무엇이 필요한지 설명 가능하다. 원하는 형태의 타입을 리턴할 수 있다. 인터페이스 뒤에 실제 객체의 구현을 숨길 때 유용하게 사용할 수 있다. lisOf는 List인터페이스를 리턴한다. 실제로 리턴하는 객체는 플랫폼에 따라 다름 호출될 때마다 새로운 객체를 만들 필요가 없다. 싱클턴 패턴처럼 객체를 하나만 생성하게 강제가능하다. 아직 존재하지 않는 객체를 리턴할 수 있다. 앞으로 만들어질 객체를 사용하거나,프록시를 통해 만들어지는 객체를 사용할 수 있다. Proxy.*newProxyInstance*() 팩토리 함수는 인라인으로 만들 수 잇으며, 파라미터들을 reif.. Reading Record/이펙티브 코틀린 2022. 6. 7.
ㅤㅤㅤㅤㅤ
By nathan_H
[이펙티브 코틀린] Item 31 - 32. 문서 규약과 추상화 규약 Item 31. 문서로 규약을 정의하라 함수가 무엇을 하는지 명화갛게 설명하고 싶다면 KDoc 주석을 붙여주는 것이 좋음 /** * 이 프로젝트에서 짧은 메시지를 사용자에게 출력할 때 사용하는 기본 방식 * @param message 사용자에게 보여 줄 메시지 * @param length 메시지의 길이가 어느정도 되는지 나타내는 enum 값 */ fun Context.showMessage( message: String, duration: MessageLength = MessageLength.LONG, ) { val toastDuration = when (duration) { MessageLength.SHORT -> Length.LENGTH_LONG MessageLength.LONG -> Length.LE.. Reading Record/이펙티브 코틀린 2022. 5. 29.
ㅤㅤㅤㅤㅤ
By nathan_H
[이펙티브 코틀린] Item 28 ~30. API 안정성 및 가시성 Item 28. API 안정성을 확보하라 프로그래밍에서는 안정적이고 표준 API를 선호하는데 그 이유는 아래와 같음 API가 변경되고 개발자가 이를 업데이트 했다면 여러 코드를 수동으로 업데이트 해야함 많은 곳에서 api에 의존적이면 변경사항이 많을 수 있음 사용자가 새로운 API를 배워야함 변경된 api를 쓰는 쪽에서는 변경사실을 알아야 하고 변경 부분에 대한 이해가 필요함 한번에 안정적인 API가 나왔으면 하지만 좋은 API 설계는 어렵기 때문에 우선 만들고 지속적으로 발전시켜 나가야 한다. 그래서 API 안정성을 지정해서 정보를 제공함으로써 api를 사용하는 곳에서 안정성을 확인할 수 있음 안정성 제공에 가장 간단한 방법은 문서에서 API 일부가 불안정한지 명확하게 지정 버전을 사용해 전체 라이브러.. Reading Record/이펙티브 코틀린 2022. 5. 29.
ㅤㅤㅤㅤㅤ
By nathan_H
[이펙티브 코틀린] Item 27. 변화로부터 코드를 보호하려면 추상화를 사용하라 추상화를 잘하면 세부 사항을 잘 알지 못하더라도 변경에 자유로워짐 상수 리터럴을 상수 프로퍼티로 변경하게 되면 해당 값을 이름을 붙일 수 있고 값을 변경할때에 훨씬 쉽고 안전하게 변경이 가능하게됨 Before fun isPasswordValid(text: String): Boolean { if (text.length < 7) return false } After const val MIN_PASSWORD_LENGTH = 7 fun isPasswordValid(text: String): Boolean { if (text.length < MIN_PASSWORD_LENGTH) return false } 이런식으로 상수로 빼면 장점 의미있는 이름 부여 값 변경에 안전함 함수 사용자에게 토스트 메시지를 자주 출력해.. Reading Record/이펙티브 코틀린 2022. 5. 29.
ㅤㅤㅤㅤㅤ
By nathan_H
[이펙티브 코틀린] Item 26. 함수 내부의 추상화 레벨을 통일하라 컴퓨터 과학에서의 추상화 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것 추상화가 필요한 이유 복잡성을 숨기고 사용되는 단순한 형식만 노출해 코드를 체계화하고 만드는 사람에게 변화의 자유를 주기 위해 추상화를 사용 자동차의 경우 내부적으로는 매우 복잡한 요소들이 많지만 추상화된 핸들과 변속기 가속페달만으로 자동차를 운전할 수 있음 → 굉장히 추상화가 잘된 예시 추상화 레벨 높은 레벨로 갈수록 물리 장치에서 멀어지고 프로그래밍에서는 일반적으로 높을 레벨일수록 프로세스와 멀어지고 관리해야하는 세부적인 내용이 적음 ex) C언어는 직접 메모리를 제어할 수 있지만 비교적 JVM 언어에 비해 복잡도가 높음 추상화 레벨 통일 코드도 추상화를 계층처럼 만들어서 사용할 수 있는데, 이.. Reading Record/이펙티브 코틀린 2022. 5. 29.
ㅤㅤㅤㅤㅤ
By gobukgol
[이펙티브 코틀린] Item25. 공통 모듈을 추출해서 여러 플랫폼에서 재사용하라 풀스택 개발 최근 코틀린은 백엔드 개발을 위한 자바의 대안이 되고 있음 코틀린은 자바스크립트로 컴파일 될 수 있음 이미 많은 코틀린/JS 라이브러리 존재 코틀린은 웹 백엔드와 프론트엔드를 만들 수 있다는 장점이 있다. 이는 단순하게 만들 수 있다는 개념을 떠나서, 서로 코드를 공유할 수도 있다는 뜻 따라서 공통 코드, API 엔드포인트 정의, 추상화 등을 재사용 할 수 있음 모바일 개발 코틀린의 멀티 플랫폼 기능을 활용하면, 로직을 한 번만 구현하고, 두 플랫폼에서 이를 재사용할 수 있음 공통 모듈을 만들고, 다양한 비즈니스 로직을 구현하면 됨 비즈니스 로직은 프레임워크와 플랫폼에 종속되지 않고 독립적이어야 한다. 안드로이드는 Gradle을 사용해서 동일한 방법으로 만들어지므로 직접 사용할 수 있음 iO.. Reading Record/이펙티브 코틀린 2022. 5. 2.
ㅤㅤㅤㅤㅤ
By gobukgol
[이펙티브 코틀린] Item24. 제네릭 타입과 variance 한정자를 활용하라 class Cup : variance 한정자가 없으므로 기본적으로 invariant(불공변성) Cup, Cup, Cup 은 어떠한 관련성이 없음 class Cup : 타입 파라미터를 convariant(공변성)으로 만듦 A가 B의 서브 타입일 때, Cup가 Cup의 서브타입이라는 의미 Class Cup : 타입 파라미터를 contravariant(반변성)으로 만듦 A가 B의 서브 타입일 때, Cup가 Cup의 슈퍼타입 함수 타입은 파라미터 유형과 리턴 타입에 따라서 서로 어떤 관계를 갖는다. (Int) -> Any 타입의 함수는 아래와 같은 함수로도 동작한다. (Int) -> Number (Number) -> Any (Number) -> Number (Number) -> Int 코틀린 함수 타입의 모든 .. Reading Record/이펙티브 코틀린 2022. 5. 2.

티스토리툴바