onCreateView와 onViewCreated의 차이

yeonkims — Sat, 1 Nov 2025 18:58:31 +0900

onCreateView()

“Fragment의 XML을 메모리에 올리고(binding), root view를 반환하는 단계”

역할: 레이아웃 inflate + binding 연결
이 시점에는 뷰가 “만들어지는 중”이라, 아직 Activity에 완전히 붙지 않았고 화면 표시도 안 된 상태이다.
그래서 여기서는 최소한의 일만 하는 게 원칙

override fun onCreateView(
    inflater: LayoutInflater, container: ViewGroup?,
    savedInstanceState: Bundle?
): View {
    _binding = FragmentSampleBinding.inflate(inflater, container, false)
    return binding.root
}

onViewCreated()

“뷰가 다 만들어졌으니, 이제 조립하고 동작을 붙이는 단계”

역할: UI 초기화, 리스너 연결, Adapter 세팅, LiveData/Flow 관찰 등
이제 binding.root가 Activity에 attach되었기 때문에
requireContext(), viewLifecycleOwner, binding.xxx 전부 안전하게 쓸 수 있다.

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)

    setupRecyclerView()
    setupSpinners()
    setButtonListeners()
    observeViewModel()
}

요약

메서드	시점	해야 할 일	하지 말아야 할 일
onCreateView	뷰 “만드는 중”	XML ↔ Fragment 연결 (inflate, binding 생성)	리스너/Flow 수집/Adapter 연결
onViewCreated	뷰 “다 만들어짐”	리스너, Adapter, Flow, Livedata 등 UI 초기화	—

한 줄 정리

onCreateView에서는 “뷰를 만들기만” 하고,
onViewCreated에서 “그 뷰를 세팅하고 움직이게” 한다.

이것이 Fragment의 생명주기에서 가장 중요한 패턴이며,
실무에서도 “inflate는 onCreateView, 나머지는 onViewCreated”가 표준이다.

[Android] 최신 안드로이드 MVVM + StateFlow 표준 패턴

yeonkims — Sat, 1 Nov 2025 18:54:34 +0900

Repository → ViewModel(StateFlow) → UI(Fragment/Compose) 두 가지 UI 버전 예시에 포함됨.

0) 모델 & UI 상태

// domain/model
data class User(val id: String, val name: String)

// presentation/state
data class UserUiState(
    val loading: Boolean = false,
    val data: List<User> = emptyList(),
    val error: String? = null
)

1) DataSource & Repository (Flow로 데이터 제공)

// data/remote
interface UserRemoteDataSource {
    suspend fun fetchUsers(): List<User>
}

// data/repo
class UserRepository(
    private val remote: UserRemoteDataSource
) {
    // Flow로 비동기 데이터 스트림 제공
    fun users(): Flow<Result<List<User>>> = flow {
        emit(Result.success(remote.fetchUsers()))
    }.catch { e ->
        emit(Result.failure(e))
    }
}

실제론 Room/Network를 combine하거나 emitAll(roomDao.flow())처럼 섞기도 함.

2) ViewModel (Flow → StateFlow 변환: 핵심)

class UserViewModel(
    private val repo: UserRepository
) : ViewModel() {

    // Repository의 Flow를 UI가 쓰기 좋은 StateFlow<UserUiState>로 변환
    val uiState: StateFlow<UserUiState> =
        repo.users()
            .map { result ->
                result.fold(
                    onSuccess = { UserUiState(loading = false, data = it, error = null) },
                    onFailure = { UserUiState(loading = false, data = emptyList(), error = it.message) }
                )
            }
            // 로딩 신호를 주고 싶다면 시작 전에 한 번 emit
            .onStart { emit(UserUiState(loading = true)) }
            // 같은 상태 연속 방출 방지
            .distinctUntilChanged()
            // **표준 패턴:** ViewModel 스코프 + WhileSubscribed(유예 5초) + 초기값
            .stateIn(
                scope = viewModelScope,
                started = SharingStarted.WhileSubscribed(5_000),
                initialValue = UserUiState(loading = true)
            )

    // 예: 새로고침 트리거
    fun refresh() {
        viewModelScope.launch {
            // 필요시 repo 호출 로직 추가
        }
    }
}

3A) UI: Fragment + ViewBinding (생명주기 안전 수집)

class UserFragment : Fragment(R.layout.fragment_user) {

    private var _binding: FragmentUserBinding? = null
    private val binding get() = _binding!!
    private val viewModel: UserViewModel by viewModels()

    override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?
    ): View {
        _binding = FragmentUserBinding.inflate(inflater, container, false)
        return binding.root
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        // 어댑터/리스너 세팅 등 UI 초기화…
        setupRecycler()

        // **표준 수집 패턴**
        viewLifecycleOwner.lifecycleScope.launch {
            viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                viewModel.uiState.collect { state ->
                    binding.progressBar.isVisible = state.loading
                    binding.errorText.isVisible = state.error != null
                    binding.errorText.text = state.error ?: ""

                    submitUsers(state.data)
                }
            }
        }

        binding.refreshBtn.setOnClickListener { viewModel.refresh() }
    }

    override fun onDestroyView() {
        super.onDestroyView()
        _binding = null
    }

    private fun setupRecycler() { /* ... */ }
    private fun submitUsers(users: List<User>) { /* adapter.submitList(users) ... */ }
}

3B) UI: Jetpack Compose (collectAsState)

@Composable
fun UserScreen(viewModel: UserViewModel = hiltViewModel()) {
    val state by viewModel.uiState.collectAsState() // StateFlow → Compose State

    when {
        state.loading -> CircularProgressIndicator()
        state.error != null -> ErrorBox(state.error!!) { viewModel.refresh() }
        else -> UserList(state.data)
    }
}

@Composable
fun ErrorBox(msg: String, onRetry: () -> Unit) {
    Column {
        Text(text = msg)
        Button(onClick = onRetry) { Text("Retry") }
    }
}

4) 왜 이게 “현업 표준”인가 (핵심 포인트 요약)

Repository는 Flow로 데이터 발행 → 테스트/교체 쉬움.
ViewModel에서 map/onStart/distinctUntilChanged/stateIn
- stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), initial) = 정석 패턴
- “구독 있을 때만 실행 + 5초 유예 + 초기값 보유”
**Fragment는 repeatOnLifecycle(STARTED)**로 생명주기 안전 수집
- View가 사라지면 자동 중단, 다시 보이면 재시작.
Compose는 collectAsState() 하나로 끝 → 선언형 UI와 찰떡.

5) 자주 하는 확장/추가

UIState를 sealed class로 만들고 Loading/Success/Error로 구분해도 좋음.
이벤트(토스트/네비게이션)는 SharedFlow(replay=0)로 별도 관리.
Repository에서 Room.flow()와 네트워크 flow를 combine/flatMapLatest로 합침.
WhileSubscribed(5_000)의 5초는 팀 컨벤션에 따라 1~5초. 상수로 빼두면 더 깔끔 (GRACE_MS = 5_000).

[Android] Flow에서의 map

yeonkims — Sat, 1 Nov 2025 18:49:44 +0900

Flow에서의 map의 의미

프래그먼트 쪽 collect { show -> ... }는 showPickNumberSpinner 값이 바뀔 때마다 람다를 실행해서 스피너 isVisible을 토글한다.

mode가 바뀌면 → 그 변화를 map { ... }이 반영 → showPickNumberSpinner가 자동으로 바뀐다.

(1) _mode (MutableStateFlow<Mode>)  ← 여기 값을 바꿈 (업스트림)
        │ emits
        ▼
(2) mode: StateFlow<Mode> (= _mode.asStateFlow())
        │ map { it != RANK && it != DICE }
        ▼
(3) showPickNumberSpinner: StateFlow<Boolean>
        │ collect (Fragment에서 수집)
        ▼
(4) UI 업데이트 (Spinner isVisible 토글)

(1)에서 실제로 값이 바뀌는 지점이 필요합니다.
(2) → (3)은 파생: mode가 emit될 때마다 map이 실행되어 Boolean으로 변환됩니다.
(4)는 프래그먼트가 수집하고 있으니, 값이 바뀔 때마다 UI가 갱신됩니다.

즉, 보통 ViewModel 안에 이런 코드가 있어야 한다:

_mode.value = newMode

emit 함수를 직접 사용하지 않더라도,

MutableStateFlow에 value를 대입하는 순간 (값을 갱신하는 순간)이 곧 emit 이다.

_mode.value = newMode   // ← 이 한 줄이 'emit(newMode)'와 같은 효과

두 방식의 비교

private val _mode = MutableStateFlow(Mode.PICK)
val mode: StateFlow<Mode> = _mode.asStateFlow()

fun updateModeImmediate(newMode: Mode) {
    // 바로 변경 — 일반 함수에서도 가능
    _mode.value = newMode
}

suspend fun updateModeSuspend(newMode: Mode) {
    // 코루틴 내부에서만 가능 (예: repository 콜백 안)
    _mode.emit(newMode)
}

실제 현업에서는?

대부분의 UI 상태(StateFlow) 는 메인스레드에서 즉시 변경되니까 value = 방식을 거의 표준으로 쓴다.
반면, suspend 함수나 flow 연산자 내부에서 emit해야 할 때는 emit()을 사용한다.

[Android] 자주 쓰이는 3가지 오버로딩 map 함수들

yeonkims — Sat, 1 Nov 2025 18:38:03 +0900

1. List / Iterable용 map

// kotlinx.coroutines.flow.FlowKt__TransformKt
public fun <T, R> Flow<T>.map(transform: suspend (T) -> R): Flow<R> =
    unsafeTransform { value -> emit(transform(value)) }

즉시 계산, 자료구조를 바꿔서 새 컬렉션을 리턴

2. Sequence용 map

// kotlin.sequences.Sequences.kt
public fun <T, R> Sequence<T>.map(transform: (T) -> R): Sequence<R> {
    return TransformingSequence(this, transform)
}

지연 계산, 필요할 때만 계산
TransformingSequence는 실제로 iterator()가 돌기 전까지 아무 일도 안 함.

3. Flow용 map

// kotlinx.coroutines.flow.FlowKt__TransformKt
public fun <T, R> Flow<T>.map(transform: suspend (T) -> R): Flow<R> =
    unsafeTransform { value -> emit(transform(value)) }

비동기 반응, 값이 들어올 때마다 emit
collect가 시작되면, upstream이 emit할 때마다 transform(value) 실행 → downstream에 emit.

실전에서 if-else 대신 enum + when 구조를 써야하는 이유

yeonkims — Fri, 31 Oct 2025 19:51:50 +0900

FingerPick 업데이트로 새로운 모드를 추가하던 중,

과거에 해당 구조를 사용함으로써 이번에 작업을 수월하게 한 경험을 기록한다.

새로운 enum 값이 추가되면, else가 있는 경우엔 버그가 숨어들 가능성이 높아지게 되는데,

else 없는 when을 사용해 두면 컴파일러가 "이 모드 처리 안 했잖아!" 하고 알려주게 되어 버그를 줄일 수 있다.

val pickNumbers = when (mode) {
    Mode.PICK, Mode.RANK -> ...
    Mode.TEAM -> ...
    Mode.DICE -> ...
}

즉, 이러한 enum Class + when 구조는 모든 경우를 다 다루고 있다는 검증을 컴파일러가 체크해준다.

풀어 설명하면 enum class나 sealed class를 when문에 넣으면, 모든 가능한 값(분기)을 다 처리했는지 컴파일러가 검사한다는 뜻이다.

모든 경우를 빠짐없이 처리했다는 '보증'

else는 "나머지 값들은 다 여기로 들어와" 라는 뜻이다.

그런데 enum이나 sealed class는 가능한 값이 명확히 한정돼 있기 때문에,
else로 처리하면 오히려 컴파일러가 ‘빠진 케이스’를 인식할 수 없게 된다.

예를 들어,

enum class Mode { PICK, TEAM, RANK }

val pickNumbers = when (mode) {
    Mode.PICK -> ...
    Mode.TEAM -> ...
    else -> ...  // 여기서 RANK 포함됨
}

이 상태에서 나중에 Mode.DICE를 새로 추가해도,
컴파일러는 “else 있으니까 괜찮네”라고 경고를 하지 않는다.

즉, DICE가 처리되지 않아도 앱은 그대로 빌드되어 버그 가능성이 높아진다.

반면, else를 빼면?

enum class Mode { PICK, TEAM, RANK }

val pickNumbers = when (mode) {
    Mode.PICK -> ...
    Mode.TEAM -> ...
    else -> ...  // 여기서 RANK 포함됨
}

이 상태에서 Mode.DICE를 enum에 추가하면?

"when’ expression must be exhaustive"

→ 컴파일러가 강제로 알려준다.

그래서 모드가 추가되면 무조건 처리 코드를 써야 한다는 게 보장된다.
즉, 미래의 나(혹은 동료)가 새로운 모드를 추가할 때 자동으로 "리마인드"가 되는 구조이다.

else를 대신 exhaustive when을 사용하는 것은 단순한 취향 문제가 아니라,
명확성 + 안정성 + 유지보수성을 크게 높여주는 것이다.

콜백 함수를 이용한 관심사 분리

yeonkims — Wed, 3 Sep 2025 19:12:42 +0900

removeTouchCallback의 역할은?

removeTouchCallback은 게임 로직에서 ViewModel로 "이 터치를 화면에서 제거해줘"라고 요청하는 콜백 함수이다.

역할:

- GameLogic → ViewModel 통신: Strategy 패턴에서 게임 로직이 UI 상태를 직접 조작할 수 없으므로, 콜백을 통해 ViewModel에게 터치 제거를 요청

- 관심사 분리: 게임 로직은 "누구를 선택할지" 결정만 하고, 실제 터치 데이터와 애니메이션 관리는 ViewModel이 담당

- 의존성 역전: 게임 로직이 ViewModel에 의존하지 않고, 인터페이스(콜백)에만 의존

동작 흐름:

1. PickLogic이 랜덤 선택 후 removeTouchCallback(pointer)로 제거 요청

2. ViewModel의 _removeTouch(pointer)가 실행되어 실제 터치 데이터 삭제와 애니메이션 해제

이렇게 하면 각 계층의 책임을 명확히 분리할 수 있다.

콜백 실행 순서

  1. finger_pick_view_model.dart:play - 게임 시작, _removeTouch 콜백을 GameEngine에 전달
  2. game_engine.dart:run - 받은 콜백을 GameLogic에 그대로 전달
  3. game_logic.dart:PickLogic.run - 랜덤 선택 후, 선택되지 않은 터치들에 대해 removeTouchCallback(pointer) 호출
  4. finger_pick_view_model.dart:_removeTouch - 콜백으로 실행되어 실제 터치 데이터 삭제 및 애니메이션 해제

  흐름 요약:
  ViewModel.play → GameEngine.run → PickLogic.run → ViewModel._removeTouch

콜백은 PickLogic이 "이 pointer는 제거해줘"라고 ViewModel에게 간접적으로 요청하는 방식이다. 직접 참조 대신 콜백을 사용해서 Strategy 패턴의 의존성 분리를 유지할 수 있다.

Dart, Flutter의 required 키워드

yeonkims — Tue, 26 Aug 2025 19:39:28 +0900

required?

Dart에서는 Named parameter(이름 있는 파라미터)가 많다.
기본적으로는 optional(선택)이라서 안 넣어도 됨.
required를 붙이면 “이거 꼭 줘야 돼”라는 의미가 된다.

예시:

void greet({required String name, int? age}) {
  print("Hello $name");
}

greet(name: "Jiyeon"); // OK
greet(); // ❌ 컴파일 에러 (name 안 줌)

→ 즉, required는 “이 파라미터는 무조건 넣어야 한다”는 약속.

(코틀린의 fun greet(name: String, age: Int? = null)과 비슷한데, Dart는 named param에서 required로 강제할 수 있음.)

Dart에서 final 키워드, 왜 이렇게 많이 쓰는가

yeonkims — Tue, 26 Aug 2025 19:39:02 +0900

자바나 코틀린에서의 final = “상수(변경 불가)” 개념이랑 비슷함.
근데 Dart는 이걸 아주 광범위하게 적용할 수 있음:

변수/필드 앞 → 값 재할당 불가 (Java의 final 변수, Kotlin의 val)

final name = "Jiyeon"; // 한 번만 할당 가능

클래스 앞 → 이 클래스는 더 이상 상속할 수 없음 (Java의 final class, Kotlin의 final 기본값과 비슷)

final class A {}

생성자 매개변수 앞 → 읽기 전용 필드로 고정됨

class Person {
  final String name;
  Person(this.name); // 여기서 name은 생성자 때만 정해지고 이후 변경 불가
}

지역 변수, 루프 변수 등등
→ 어디서든 값 재할당 막을 때 final을 써서 불변성(immutability)을 강조하는 것.

왜 이렇게 final을 강조할까?

버그 예방: 실수로 값 바꾸는 걸 막음
가독성: “이 값은 절대 안 바뀌는구나” 한눈에 보임
최적화: Dart VM/컴파일러가 불변값을 더 공격적으로 최적화할 수 있음
의도 표현: 협업 시 다른 개발자에게 “여긴 불변이야!”라고 명확하게 알려줌

→ 즉, Dart/Flutter 커뮤니티에서는 “가능하면 무조건 final 써라”가 일종의 베스트 프랙티스다.
코틀린에서 val을 기본으로 쓰는 거랑 같은 철학이라고 보면 됨.

Strategy 패턴 실제 적용 정리

yeonkims — Tue, 26 Aug 2025 19:14:12 +0900

하나의 스크린에서 동작하는 각 게임 모드에 대한 대한 게임로직을 만들어야 하는 상황.

game_engine.dart에 모두 때려박아야 하는가?

(예를들어 GameEngine 클래스의 gameResult()라는 메소드에서 게임 모드에 따라 switch문으로 분기시키기)

아니면 모드를 전략(Strategy)으로 분리하는게 좋은가?

당연히 Strategy 패턴을 이용하여 테스트·확장성·가독성·버그 격리도를 향상시키는게 좋다.

확장성: 새로운 모드 추가해도 기존 코드 최소 변경(레지스트리에만 등록).
테스트 용이: 각 로직을 단독 유닛테스트 가능, seed로 결과 재현.
UI 분리: 엔진은 순수 로직, ChangeNotifier/ViewModel은 상태만 관리.
안전성: 참가자 수/팀 개수 검증을 각 전략에 국한 → 버그 영향 범위 축소.

"switch 한 방" 접근이 안 좋은 이유

모드가 늘수록 switch가 비대해지고 테스트가 어려워짐
공통/특수 케이스 섞이면서 사이드이펙트 늘어남
OCP(Open-Closed Principle) 위반: 새 모드 추가 때 기존 코드 자주 수정

엔진은 순수(Pure) 로직으로 두고, UI/상태는 ViewModel이 맡게 하자.

설계 구조 (Strategy 패턴 + Registry)

엔진은 공통 인터페이스만 노출
각 모드별 로직은 별도 클래스로 분리
enum ↔ 전략 매핑은 레지스트리(Map)로 관리

enum GameMode

• 아래에 sealed class GameResult를 만들었는데 왜 여전히 enum GameMode는 필요한가?

enum GameMode

게임을 실행하기 전에 “어떤 모드로 돌릴지”를 선택하는 정보.
즉, 입력(선택지) 단계에서 필요.
ViewModel이나 UI에서 사용자가 "A / B / C"를 고르면 이게 바로 GameMode.

sealed class GameResult

반대로, 게임을 실제로 실행한 뒤 나오는 결과의 형태를 나타냄.
즉, 출력(결과) 단계에서 필요.
A모드면 AResult, B모드면 BResult 이런 식으로 갈라짐.

(비유)

enum GameMode = 게임 메뉴판 (어떤 게임을 고를지 선택)

sealed GameResult = 게임 끝나고 나온 점수판/결과표

둘은 시점과 책임이 다르기 때문에 둘 다 필요.

만약 GameMode를 없애면?

UI에서 "Pick 모드로 실행" 같은 선택을 표현하기가 힘들어짐.
그럼 결국 PickLogic, TeamLogic, RankLogic을 직접 객체로 다뤄야 함 → 코드가 더 복잡해짐.

즉, GameMode는 UI/엔진 사이의 단순한 계약(토글 값) 역할을 해서 실무에서 굉장히 편함.

// 1) 결과 타입 : sealed class로 모드별 결과 표현 
sealed class GameResult {}

• 비어있는 GameResult로 굳이 게임별 결과를 표현하는 이유

→ 모든 게임 결과의 부모 틀이라고 보면 됨.
각 게임의 결과가 전부 GameResult를 상속하니까, 최종 엔진에서는 그냥 GameResult 하나만 반환하면 된다.

// 1-2) 모드별 결과 정의 
final class ~Result extends GameResult { 
	~Result(this.x) 
}

// 2) 전략 인터페이스
abstract interface class GameLogic { 
	GameResult run({…}) 
}

• 전략 인터페이스?

→ 전략 패턴(Strategy Pattern)”이란 디자인 패턴 사용
알고리즘(전략)을 외부로 빼서 갈아 끼우는 구조

GameLogic = 게임 돌리는 방법을 약속한 틀(계약).
ALogic, BLogic, CLogic = 실제 게임별 전략(알고리즘).

• abstract interface class라는 긴 키워드는 Dart3에서 새로 생긴 문법.

Dart에서 저렇게 쓴 건, 자바/코틀린으로 치면 그냥 interface GameLogic이랑 제일 가까움.

(Java/Kotlin: abstract interface 같은 건 없음. interface와 abstract class가 별도로 존재.)

abstract = 이 클래스는 직접 new 못 함 (미구현 메소드 있어도 됨)
interface class = 다른 클래스가 상속(extends) 은 못 하고, 오직 구현(implements) 만 가능
→ 즉, "진짜 인터페이스처럼만 쓰이는 추상 클래스"를 만든 것.

// 3) 공통 설정 (팀 개수 등) 
class GameConfig

// 4) 모드별 구현 
final class ~Logic implements GameLogic

• final class?

→ 이 클래스를 더 이상 상속 못 한다는 의미.
즉, ~Logic은 그냥 딱 하나의 확정된 구현체! 라는 뜻.

implements GameLogic → GameLogic(계약서)에 적힌 함수들을 반드시 구현해야 한다.
즉, “이 클래스는 Pick 전략을 담당한다”라고 선언하는 것임.

// 5) 엔진 (순수함수 스타일, 상태 없음) 
final class GameEngine

• GameEngine을 왜 상태 없이 만들었는가?

→ 순수 계산기처럼 만들고 싶어서.

입력 넣으면 → 결과 뱉음. 끝.
안에 상태가 없으니까, 여러 번 호출해도 항상 예측 가능.
테스트하기 쉽고, UI/상태랑 분리됨.

즉, “엔진은 계산만 한다, 나머지는 ViewModel이 관리한다” 이런 철학.

• 엔진부분의 registry?

→ registry는 쉽게 말해서 모드 ↔ 전략 객체”를 연결해둔 Map 이다.

final Map<GameMode, GameLogic> _registry = {
  GameMode.A: ALogic(),
  GameMode.B: BLogic(),
  GameMode.C: CLogic(),
};

GameEngine이 직접 switch를 쓰지 않고, 이 레지스트리에서 찾아서 실행하는 것.

즉, 중앙에서 모드별 구현체를 등록/관리하는 구조.

Strategy 패턴 = 알고리즘을 인터페이스로 빼고 갈아 끼우는 것
Registry = 미리 Map 같은 데에 등록해두고 필요할 때 꺼내 쓰는 것

결국 목적은: switch 문 안 쓰고 깔끔하게 확장성 확보.
새 모드 추가하면 그냥 registry에만 등록하면 끝.

Dart - 자동 기본 생성자

yeonkims — Tue, 26 Aug 2025 18:29:32 +0900

class A { A(); }

이 코드는 Dart 문법으로 작성된 클래스 선언이다.

의미를 풀어보면:

class A { ... }
→ A라는 이름의 클래스를 정의한 것.
A();
→ A 클래스의 기본 생성자(default constructor) 를 명시적으로 정의한 것.
Dart에서는 생성자를 생략하면 자동으로 A(); 라는 기본 생성자가 제공됨.

즉, 아래 두 코드는 완전히 동일한 의미이다:

class A { A(); // 기본 생성자 (직접 정의) }


class A { // 아무 생성자도 정의하지 않으면, 자동으로 A(); 생성자가 만들어짐 }

정리하자면:
이 코드는 "A라는 클래스를 만들고, 매개변수가 없는 기본 생성자를 명시적으로 선언한다"는 뜻

언어별 기본 생성자 여부

C	❌ (개념 없음)
Kotlin	✅
Java	✅ (단, 다른 생성자 정의하면 ❌)
Python	✅ (object.__init__)

Flutter 코드에서 ChangeNotifier 기반 ViewModel 만들 때 ClassName(); 식으로 생성자를 직접 정의하는 경우가 종종 나온다.

왜 이렇게 쓰냐?

명시적으로 써주는 이유

나중에 생성자에 매개변수 넣을 가능성을 대비
super 생성자 호출을 명시해야 하는 경우 (예: super(key) in StatelessWidget)
코드를 읽는 사람 입장에서 “여기에 생성자가 있다”는 걸 눈에 보이게 해줌

즉, 없어도 되는데 “명시성” 때문에 작성하는 경우가 많다.

Archive