# Kotlin Explicit Backing Fields: Encapsulation Tradeoffs and Downcasting Risks

DevFeed: [Kotlin Explicit Backing Fields: Encapsulation Tradeoffs and Downcasting Risks](<https://devfeed.tech/articles/the-downcast-trap-in-kotlin-s-explicit-backing-fields-22951.md>)

Original publisher: [Read original article](<https://proandroiddev.com/the-downcast-trap-in-kotlins-explicit-backing-fields-626ef0d66e50?source=rss----c72404660798---4>)

Author: Ehab Elwan

Published: 2026-09-13T05:31:32Z

Content type: opinion

Language: en

Sources: [ProAndroidDev - Medium](<https://devfeed.tech/sources/proandroiddev-medium.md>)

Topics: [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Code](<https://devfeed.tech/topics/code.md>), [Jetpack Compose](<https://devfeed.tech/topics/jetpack-compose.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-development](<https://devfeed.tech/tags/android-development.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [article](<https://devfeed.tech/tags/article.md>), [clean-code](<https://devfeed.tech/tags/clean-code.md>), [code](<https://devfeed.tech/tags/code.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [memory](<https://devfeed.tech/tags/memory.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [stateflow](<https://devfeed.tech/tags/stateflow.md>)

## AI overview

This article compares Kotlin's traditional private mutable property plus public read-only wrapper with explicit backing fields. It explains that explicit backing fields can avoid an extra wrapper allocation, but because the underlying object remains mutable, an external downcast may bypass the intended read-only restriction and mutate internal state.

## Source excerpt

Why eliminating the double-property boilerplate changes how we protect our architecture Image generated by AIDisclosure: This article was drafted by me and refined with the help of AI tools. If you have written Kotlin in the last few years, you are intimately familiar with the double-property boilerplate. Whether in Android ViewModels or general state holders, maintaining a private mutable property alongside a public read-only property is a chore we have all accepted in the name of strict encapsulation to prevent our internal state from being hijacked by outside classes. It makes the code significantly cleaner (and slightly more memory efficient). However, it fundamentally changes how we protect our state, moving from a physical object boundary to a simple type restriction. Let's look at the tradeoff. The Old Way: Wrapper Protection For years, the standard approach to encapsulating state has looked like this: class OldViewModel { // 1. The private mutable state private val _uiState = MutableStateFlow(UiState()) // 2. The public read-only state val uiState: StateFlow<UiState> = _uiState.asStateFlow() } This is tedious to write, but it provides a strict architectural guarantee. When you call .asStateFlow(), Kotlin does not just change the type; it creates a brand new wrapper object in memory (ReadonlyStateFlow). While this physical barrier is fantastic for safety, it does mean you are incurring a minor memory allocation overhead by creating a secondary wrapper object for every exposed state. The New Way: Upcasting Explicit Backing Fields allow you to merge these two properties into one concise declaration, bypassing that extra memory allocation entirely: class NewViewModel { val uiState: StateFlow<UiState> field = MutableStateFlow(UiState()) } Inside your class, the Kotlin compiler smart-casts the field so you can mutate it internally. Outside the class, the compiler restricts callers to the read-only StateFlow interface. It looks incredibly clean and saves an allocat