# lateinit

lej7122

늦은 초기화 기법 with Kotlin 늦은 초기화는 객체 초기화를 나중에 하는 것이다. 예를 들어 변수 a를 사용할 예정이지만, a의 첫 상태를 정의하기 어려울 때 사용된다. a를 null로 초기화하는 방법도 있지만 kotlin에서는 null 사용을 지양한다. 따라서, 늦은 초기화 기법을 위해 대표적으로 두 방법을 사용하고 있다. lateinit lateinit을 사용하여 var 형태의 변수 x가 나중에 사용될 것이며, String 타입이라는 것만 정해준다. 이후에 사용할 때 변수 x를 초기화하면 값이 들어간다. ("kotlin" 이라는 값으로 초기화했다) var 타입으로 변수 x를 선언했는데, lateinit을 사용하면 늦은 초기화 이후에도 값을 계속하여 변경할 수 있다. 변수 x에 값이 들어가기 전에는 null이 아니라 uninitialized(초기화되지 않음) 상태로 존재하기 때문에 null로 초기화 시 에러가 발생한다. 따라서, latein

simon3397

1. val : Value(값) 읽기전용(immutable) 이다. 한번 초기화되면 다시 할당할 수 없다. 상수 선언 시 사용. > lateinit var 2. var : Variable(변수) 가변(mutable)변수 이다. 값을 다시 할당할 수 있다. > var count = 10 count = 20 // 다시 할당 가능 3. lateinit var 나중에 초기화할 변수 선언 시 사용. 변수 선언 시 초기값을 주지 않고, 나중에 값을 할당할 수 있도록 한다. 단 초기화 전에 변수에 접근하면 예외가 발생한다. 주로 ViewBinding 및 Dagger Hilt 와 같이 나중에 초기화해야 하는 경우에 사용된다. (Android Studio) > lateinit var name: String 4. const val 컴파일 시간 상수(compile-time constant)를 선언할 때 사용. 이 변수는 컴파일 시간에 값을 알고 있어야 한다. 최상위

bom-bakbang

Android 개발자라면, 혹은 개발자가 되고 싶다면 도구인 개발 언어를 기본부터 응용까지 잘 다룰 줄 알아야 합니다. 이 포스트는 Kotlin 언어와 관련해 아래 내용들에 대해 정리합니다. ⚠️ 개인 경험을 기반으로 적은 지식이므로 잘못된 내용이나 추가로 덧붙일만한 내용이 있다면 댓글이나 개인적으로 언제든 알려주세요! >Kotlin의 기본 특징 및 Java와의 비교 > >Q) null safety의 개념이란? > >Q) mutable과 immutable 컬렉션의 차이는 무엇이며 각각 언제 쓰는 게 좋은가? > >Q) [lateinit var와 lazy delegate의 차이와 각각의 장단점은 어떻게 되는가?](#lateinit-var와-l

no1msh1217

한창 지연 초기화 방법에 대해 공부하고 있었다. 그 중에서 lateinit var를 공부하던 중 생겨난 의문점들을 탐구한 과정을 적어보려한다. 1. 왜 primitive 타입만 안될까? 검색해 볼 수도 있겠지만 디컴파일을 통해 Java에서 어떻게 표현될지를 보는게 좋을듯하다. > 일단 lateinit var로 프로퍼티를 만들어보자. lateinit은 원시타입의 프로퍼티만 가능하다는 에러가 발생하게 된다. 이걸 다시 디컴파일 해보면 내부에서 어느 부분이 에러인지 나온다. int와 null 사이에서 == 연산자를 쓸 수 없다고 나온다. 이유는 int는 값이고 null은 값이 아니기 때문이다.(null은 자바에서 특수 리터럴 값::Special literal value이라고 한다) 사과🍎와 총🔫을 비교하는 꼴이라 비교자체가 성립이 안되는 것이다. 이처럼 lateinit은 내부적으로 getter에서 임의의 변수인 var10000에 lateinit을 할 필드를 넣

dhwnsdyd28

❓지연초기화란❓ 안드로이드 코딩을 하다보면 oncreate() 함수 위에 lateinit var 를 붙인 여러가지 변수들을 만들어야 합니다. 저는 맨 처음에 코딩을 접한 것이 파이썬이었기에, 지연초기화란 개념을 아예 모르고 있었어요. 여기 이해하기 좋을 만한 두가지 비교대상 코드를 보여드릴게요. 위 코드를 chatGPT에 비교해달라고 요청한 결과, 첫번째 코드는 name이라는 private property를 지연초기화 하였고, 두번째 코드는 name이라는 객체의 자료형만 선언해주었다고 해요. ❗여기서 질문: 둘 중 좀 더 메모리효율적인 코드는 무엇일까요?❗ 답은 첫번째 코드입니다. 인터넷 검색해서는 시원하게 설명이 안되어있어서 제가 이해한 바로 설명드려볼게요. 지연 초기화는 빈 상자라고 생각하시면 되요. 클래스가 생성됨과 동시에 빈 상자를 생성해 놓는거죠. 빈 상자도 상자이긴 하니까 그 상자에 맞는 물건만 들어가겠죠? 그러나 어디까지나 상자

lijunhyeong

📌 lateinit, 늦은 초기화 > 코틀린에서는 변수를 선언할때 객체를 바로 할당하지 않는 경우에 기본적으로 컴파일이 되지 않는다. 경우에 따라 변수만 일단 선언하고 늦게 초기화를 해야할때 lateinit 프로퍼티를 사용할 수 있다. lateinit은 일단 미리 변수를 선언해놓고 이후에 값을 할당한다. var 변수만 사용 가능하고, 기본 자료형(Primitive Type) Int, Boolean, Double, Char 등등의 자료형에는 사용할 수 없다. 또한 getter와 setter도 사용할 수 없다. lateinit 초기화 확인 여부는 변수 이름 앞에 ::(콜론2개)를 붙이고 .isInitialized를 사용하면 상태를 알 수 있다. 변수를 선언한

heetaeheo

제목의 2가지는 변수를 늦게 초기화하는 방법들이다. 늦은 초기화 클래스 안에서 이 변수를 사용할 것이다 라고 선언만 해 놓고 나중에 해당 변수를 사용하는 시점에서 값을 입력해주어서 사용하는 것을 말합니다. 그냥 처음부터 null 값을 넣고 나중에 제대로 된 값을 넣으면 안되나요? 이것도 방법중 하나가 될 수 있습니다. 하지만 2가지 걸리는 상황이 있을 수 있습니다. a의 값이 변할 수는 있지만 절대 null이어서는 안되는 경우 -> 처음에 nullable한 으로 초기화해주는 것이 부적절함 a의 값이 처음 한 번만 청해지면 다시는 변하지 않는 경우 a가 var일 필요가 없습니다 . 이러한 걱정을 없애주는 문법이 lateinit과 by lazy입니다. lateinit lateinit 문법은 다음과 같은 특징이 있습니다. var 프로퍼티에서 사용가능 null을 허용하지 않음 get(),set()

min0505

늦게 초기화하기 개발하다 lateinit을 쓸 지, by lazy를 쓸 지 뭐가 맞는지 이야기가 나왔다. 그래서 정리하는 글 자 우선 이 코드를 보면 얘도 늦게 초기화 한다. a를 생각해보면 kotlin은 nullsafe인데 왜 이렇게 코딩할까 그래서 lateinit이나 by lazy를 사용한다. lateinit lateinit은 이런 식으로 나중에 초기화를 해준다. 초기화를 안하면 컴파일시 오류를 맛보게 될 수 있다. var이라서 나중에 값을 바꿀 수 있다. lateinit은 Primitive type(int, float...)에는 사용하지 못한다. by lazy 이전 글에서 썻 듯이 일단 얘는 메모리를 많이 쓴다. by lazy는 이렇게 쓴다. 얘는 val을 사용한다. 읽기 전용에만 쓰면 될 것이다. 정리 변경 가능한 값 -> lateinit 변경 불가능 값 -> by lazy 메모리 많이 쓰는 놈 -> by lazy

delvering17

lateinit (늦은 초기화) 변수를 선언하고 나서 나중에 값을 넣으려 할 때 null로 넣어 놓는 경우가 있다. 하지만 나중엔 꼭 값을 넣어야 되지만 실수로 잊어버리면 error가 날 것이다. lateinit는 그걸 방지해준다. 즉 선언은 하지만 나중에 꼭 초기화를 할 거라고 알려준다. 그러지 않으면 컴파일 에러를 낸다. 또한 값이 나중에 변경됨으로 var를 사용한다. 초기화하지 않아서 컴파일 에러를 낸다. get(), set() Java의 getter(), setter()와 비슷하다. 형식은 이렇다 변수 밑에 기본적으로 만들어져 있다. get()은 변수의 값을 return하고 set()은 변수의 값을 재정의한다. get(), set()는 사용자가 설정할 수 있는다. name 변수 처럼 get()에서 호출 시 리턴 값을 수정할 수 있고, set()에서 재정의 시 상황을 만들어 수정할 수 있다. mod

hyejiseo-dev

📍 kotlin의 변수 var : 한번 할당 된 객체를 다른 객체로 변경하여 사용할 수 있다 val : 한번 할당하면 변경할 수 없다 (단, 객체 내부 속성은 변경가능) 상수 (const) : 컴파일 시점에 결정되어 절대 변경이 불가하다 (기본 자료형만 선언 가능) 사용할 경우 Sample.CONST_A 고정적인 값으로만 사용한다 상수의 이름은 대부분 대문자와 언더바를 사용한다 변수는 런타임 시 시간이 더 소요되기 때문에 고정적으로 사용할 값을 선언해주어 성능을 향상시킬 수 있다! 📍 lateinit (늦은 초기화) Q. 자료형만 지정하고 나중에 객체를 할당하려면... > 선언과 할당을 동시에 할 수 없을 경우에는 lateinit을 사용하여 먼저 선언해두고, 나중에 할당하도록 할 수 있다! 선언 후 할당하기 전 까지는 변수 사용이 불가하다 기본 자료형에는 사용할 수 없다 (

hoyaho

평소에 안드로이드 프로젝트를 진행하면서 종종 뜨는 오류가 있었다. 바로 지연 초기화를 제대로 사용하지 않았을 때 발생하는 오류인데, 이번 기회를 통해 제대로 지연초기화에 대해 알아보고자 한다. 😪 Lazy Initialization 기본적으로 lazy 의 사전적 의미는 게으른, 느긋한, 여유로운 을 의미한다. 한마디로 위의 뜻을 직역하면 게으른 초기화 라는 의미인데, 게으른 초기화는 프로그래밍에서 꽤 긍정적인 의미로 쓰인다. 왜 지연 초기화를 사용할까? 지연 초기화라는 이름만 보아도 알 수 있듯이, 초기화 작업을 극한으로 미루다가 사용자가 필요로 할 때 진행하는데, 이 방법을 사용함으로서 메모리 낭비를 줄일 수 있다는 장점이 있다. 그리고

dear_jjwim

시작 > 혼자 공부하면서 정리하고 싶은 부분을 작성한 글입니다 👀 함께 공부하는 사람에게는 도움이 되었으면 좋겠고, 혹시 제가 잘못 이해한 부분이 있다면 알려주시면 감사하겠습니다 💌 🔹 스코프 함수 (scope function) 특정 객체의 컨텍스트 내에서 특정 동작(프로퍼티 초기화, 활용 등)을 실행하기 위한 목적만을 가진 함수 람다 함수로 사용하게 되면 임시로 scope(범위)를 형성하는데, 이 범위에서는 해당 객체의 이름 없이 접근할 수 있다. ◼ apply 객체의 확장 함수. 내부에서는 this를 통해 객체에 접근할 수 있다. (this는 생략 가능) 반환 결과가 객체 자신이기 때문에 주로 객체의 초기화에 쓰인다. ◼ also 객체가 파라미터를 통해 전달 - 람다의 입력값 람다의 입력값은 it으로 접근할 수 있고, 반환 결과는 객체이다. 객체 유효성을 확인하거나 print 함수를 통해 디버깅하는 용

silmxmail

늦은 초기화 lateinit 프로퍼티를 선언하지 않고 초기화를 미루는 방법이다. 전역 변수로 선언 후 null값을 지정하지 않고 초기화 할 수 있다. var를 이용한 경우에만 사용이 가능하다. User1의 lateData를 선언할때 초기값을 설정하지 않았다. 이것을 후에 user.lateData = "Hello" 를 통해서 사용한다. 이런것이 늦은 초기화. Lateinit의 제약 lateinit는 var로 선언한 프로퍼티에만 사용할 수 있다. lateinit는 클래스 몸체, Top-Level, 함수 내부에 선언한 프로퍼티에 사용할 수 있다. 주 생성자에서는 사용할 수 없다. lateinit는 사용자 정의 getter/setter를 사용하지 않은 프로퍼티에만 사용할 수 있다. null 허용 프로퍼티에는 사용할 수 없다. —> 절대 null이 될 수 없다. 기초 타입 프로퍼티에는 사용할 수 없다. Primitive type : Int

developer-shkim

by lazy 와 lateinit 모두 지연 초기화에 사용하는데, 어떻게 다른지 궁금해서 찾아봤습니다..! by 정의 클래스 위임 키워드 키워드로 인터페이스에 대한 구현을 다른 객체에 위임 중이라는 사실 명시 Decorator 패턴의 위임을 언어가 제공하는 일급 시민 기능으로 지원 비교 코틀린 이전 대규모 객체지향 시스템 설계 시 시스템 취약하게 만드는 문제는 보통 구현 상속에 의해 발생 하위 클래스가 상위 클래스의 메소드 중 일부 오버라이드하면 하위는 상위의 세부구현사항에 의존 코틀린 이후 위 문제를 인식하고 클래스를 기본적으로 final 로 취급 상속을 염두에 두어 open 변경자로 열어둔 클래스만 확장 가능 open 변경자를 보고, 변경 시 하위 클래스를 깨지 않도록 신경을 쓸 수 있다. Decorator 패턴 상황 종종 상속을 허용하지 않는 클래스에 새로운 동작을 추가해야 할