본문 바로가기
728x90

전체 글249

아이템 19 - knowledge 를 반복하여 사용하지 말라 저자가 생각하는 프로그램의 가장 큰 규칙은 다음과 같다 프로젝트에서 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다. 실용주의 프로그래머 라는 책에서는 DRY 규칙(Don't Repeat Yourself)으로 표현하고 있다. 프로그래밍에서 knowledge 는 넓은 의미로 의도적인 정보 를 뜻합니다. 프로그램에서 중요한 knowledge 를 크게 두 가지 뽑는다면, 다음과 같다 로직: 프로그램이 어떠한 식으로 동작하는지와 프로그램이 어떻게 보이는지 공통 알고리즘: 원하는 동작을 하기 위한 알고리즘 둘의 가장 큰 차이점은 시간에 따른 변화 이다. 비즈니스 로직은 시간이 지나면서 계속해서 변하지만, 공통 알고리즘은 한 번 정의된 이후에는 크게 변하지 않습니다. 모든것은 변화한다 프로그래밍.. 2024. 4. 16.
아이템 18 - 코딩 컨벤션을 지켜라 코틀린 코딩 컨벤션 문서 https://kotlinlang.org/docs/coding-conventions.html#naming-rules 코딩 컨벤션을 최대한 지켜 주는 것이 좋다. 인텔리제이 - Preferences > Editor > Coding Style > Kotlin > 오른쪽 상단에 Set form.. > Kotlin Style Guide 선택 생각: 지금 하던대로 가독성 있게, 잘 지키면 될듯. 2024. 4. 11.
아이템 17 - 이름 있는 아규먼트를 사용하라 코드에서 아규먼트의 의미가 명확하지 않는 경우가 있다. 예를들어 다음과 같은 코드이다. val text = (1..10).joinToString { "|" } "|" 가 무엇을 의미하는지는 joinToString 대해서 이미 알고 있다면 이것이 구분자(separator) 를 의미한다는 것을 알 것이다. 하지만 모른다면 접두사로 생각할 수도있을것이다. 명확하지 않는 경우 이를 직접 지정해서 명확하게 만들어 줄 수 있다 val text2 = (1..10).joinToString(separator = "|") 또는 val seperator = "|" val text3 = (1..10).joinToString(seperator) 또는 val test4 = (1..10).joinToString(separator .. 2024. 4. 10.
아이템 16 - 프로퍼티는 동작이 아니라 상태를 나타내야 한다 코틀린의 프로퍼티는 자바의 필드와 비슷해 보이지만, 사실 서로 완전히 다른 개념입니다. 둘 다 데이터를 저장한다는 점은 같습니다. 하지만 프로퍼티에는 더 많은 기능이 있습니다. 일단 기본적으로 프로퍼티는 사용자 정의 세터와 게터를 가질 수 있습니다. class User { var name: String = "initial name" get() = field // getter에서 백킹 필드에 접근 set(value) { field = value // setter에서 백킹 필드에 값을 할당 } } 위 코드에서 setter 에 name = value 를 하지않지 않고 field를 사용한 이유와 백킹필드란? 백킹필드 프로퍼티의 값을 저장하는 데 사용되는 내부적인 필드 코틀린에서는 프로퍼티의 값을 저장하고 검색할.. 2024. 4. 8.
아이템 15 - 리시버를 명시적으로 참조하라 리시버? 확장 함수나 확장 속성, 또는 수신 객체 람다에서 대상이 되는 객체를 의미한다 확장 함수나 속성을 호출할 때, 그 앞에 오는 객체가 바로 리시버 객체이다. 수신 객체 지정 람다에서는 람다 내부에서 사용 가능한 컨텍스트 객체를 가리킨다. 확장 함수: 특정 타입의 객체에 대해 호출되며, 그 타입의 객체가 리시버 수신 객체 지정 람다: applu, run, with, also, let 같은 함수는 모두 리시버 객체를 가지며, 람다 내부에서 직접 호출할 수 있다. fun User.printInfo() { println("Name: $name, Age: $age") // 확장 함수 내에서 'this' 생략 가능 } val user = User("injin Jeong", 10).apply { name = .. 2024. 4. 7.
apply, with, let, also, run ? apply: 개체를 생성하거나 초기화 할때 주로 사용 val peter = Person().apply { // apply 의 블록 에서는 오직 프로퍼티 만 사용합니다! name = "Peter" age = 18 } with: Non-nullable (Null 이 될수 없는) 수신 객체 이고 결과가 필요하지 않은 경우에만 with 를 사용합니다. val person: Person = getPerson() with(person) { print(name) print(age) } let: 지정된 값이 null 이 아닌 경우에 코드를 실행해야 하는 경우 getNullablePerson()?.let { // null 이 아닐때만 실행됩니다. promote(it) } val driversLicence: Licence.. 2024. 4. 7.
아이템 14 - 변수 타입이 명확하지 않는 경우 확실하게 지정하라 코틀린은 개발자가 타입을 지정하지 않아도, 타입을 지정해서 넣어 주는 굉장히 높은 수준의 타입 추론 시스템을 갖추고 있다. 이는 개발 시간을 줄여 줄 뿐만 아니라, 유형이 명확할 때 코드가 짧아지고 가독성이 크게 향상된다 하지만 유형이 명확하지 않을 때는 남용하면 좋지 않다. val data = getSomeDate() 위의 코드는 타입을 숨기고 있으며 코드를 설계할 때 읽는 사람에게 중요한 정보를 숨겨서는 안된다. 코드를 읽으면서 함수 정의를 보며 타입을 확인하면 되지 않나? 라고 생각할 수 있지만, 이는 곧 가독성이 떨어진다를 의미한다 타입을 지정해 주면, 코드를 훨씬 쉽게 읽을 수 있다 아이템3, 아이템4 를 참고해보자 생각: 요즘 ide 가 훌륭해서 크게 생각은 안해봤지만 요즘에는 함수를 들어가서.. 2024. 4. 7.
아이템 13 - Unit? 을 리턴하지 말라 Boolean 의 true, false 를 갖는 것처럼 Unit? 은 Unit 또는 null 이라는 값을 가질 수 있다. 따라서 Boolean 과 Unit? 타입은 서로 바꿔서 사용할 수 있다. 위 방법대로 Unit? 을 Boolean 을 표현하는 것은 예측하기 어려운 코드를 만들 수 있다. 따라서 Boolean 을 사용하는 형태로 변경하는 것이 좋다. 기본적으로 Unit? 을 리턴하거나, 이를 기반으로 연산하지 않는 것이 좋다. 언제 Unit? 을 사용할까? Unit? 을 사용하는 경우는 매우 드물다. Unit 은 자바의 void 와 유사한 개념이며, 묵시적으로 모든 함수에서 반환된다 Unit? 을 사용하는 것이 권장되지 않는 이유는 해당 타입이 함수가 때때로 아무것도 하지 않는 상태를 null 로 표.. 2024. 4. 7.
아이템 12 - 연산자 오버로드를 할 때는 의미에 맞게 사용하라 연산자 오버로딩은 굉장히 강력한 기능이지만, 위험할 수 있다 의미가 명확하지 않다면, infix 를 활용한 확장 함수를 사용하는 것이 좋다. 일반적인 이항 연산자 형태처럼 사용할 수 있다 infix 함수 규칙 매개변수가 반드시 필요하고, 하나의 매개변수만 가져야 합니다. infix 함수는 멤버 함수 또는 확장 함수여야 합니다. infix 함수는 suspend 될 수 없습니다(코루틴과 관련 있는 경우). // infix 함수 예시 - 1 @Test fun `p80_1`() { println("Hello".appendExclamation()) // "Hello!" println("Hello" add "World") // "Hello World" } fun String.appendExclamation(): S.. 2024. 4. 7.
728x90