# Kotlin 2.3 para Android: Desestruturação por Nome, KMP e Perguntas de Entrevista 2026 > Perguntas de entrevista sobre Kotlin 2.3 para desenvolvedores Android em 2026. Desestruturação por nome, KMP, parâmetros de contexto, Flow e coroutines com exemplos de código. - Published: 2026-05-06 - Updated: 2026-05-06 - Author: SharpSkill - Tags: kotlin, android, entrevista, kmp, coroutines - Reading time: 9 min --- A versão 2.3 do Kotlin representa um marco significativo para desenvolvedores Android, introduzindo mudanças fundamentais na forma como o código é estruturado e mantido. Com a desestruturação baseada em nome, melhorias substanciais no Kotlin Multiplatform (KMP) e refinamentos nos parâmetros de contexto, esta atualização exige atenção especial de profissionais que se preparam para entrevistas técnicas em 2026. Este artigo explora as funcionalidades mais relevantes do Kotlin 2.3, apresentando exemplos práticos e questões frequentes em processos seletivos para posições de desenvolvimento Android. > **O que mudou no Kotlin 2.3** > > O Kotlin 2.3 introduz desestruturação baseada em nome (name-based destructuring), que resolve bugs silenciosos causados pela ordem de propriedades. Também traz melhorias no KMP com suporte estável para compartilhamento de código entre Android e iOS, além de refinamentos nos parâmetros de contexto que afetam a resolução de sobrecarga de funções. ## Desestruturação Baseada em Nome: Resolvendo Bugs Silenciosos Um dos problemas mais insidiosos do Kotlin antes da versão 2.3 era a desestruturação baseada em posição. Quando desenvolvedores declaravam variáveis em uma ordem diferente das propriedades da data class, o código compilava sem erros, mas produzia resultados incorretos. ```kotlin // User.kt data class User(val username: String, val email: String) fun main() { val user = User("alice", "alice@example.com") // Position-based: order matters, not names val (email, username) = user println(email) // Prints "alice" -- wrong! println(username) // Prints "alice@example.com" -- wrong! } ``` Este comportamento causava bugs difíceis de detectar, especialmente em bases de código grandes onde refatorações podiam alterar a ordem das propriedades sem que o compilador emitisse qualquer aviso. O Kotlin 2.3 resolve este problema com três modos de compilação configuráveis que permitem uma migração gradual: ```kotlin // build.gradle.kts kotlin { compilerOptions { // Mode 1: Explicit syntax only freeCompilerArgs.add("-Xname-based-destructuring=only-syntax") // Mode 2: Warns on name mismatch // freeCompilerArgs.add("-Xname-based-destructuring=name-mismatch") // Mode 3: Full name-based by default // freeCompilerArgs.add("-Xname-based-destructuring=complete") } } ``` Com o modo completo ativado, a desestruturação passa a funcionar por correspondência de nomes, eliminando a classe de bugs descrita anteriormente: ```kotlin // NameBasedDestructuring.kt data class User(val username: String, val email: String) fun main() { val user = User("alice", "alice@example.com") // Name-based: matches by property name val (email, username) = user println(email) // "alice@example.com" -- correct println(username) // "alice" -- correct // Position-based: square brackets preserve old behavior val [first, second] = user println(first) // "alice" (component1) println(second) // "alice@example.com" (component2) } ``` A nova sintaxe com colchetes permite manter o comportamento baseado em posição quando necessário, garantindo compatibilidade retroativa com código existente. ## Kotlin Multiplatform: Compartilhamento de Código entre Android e iOS O Kotlin Multiplatform (KMP) atingiu maturidade significativa no Kotlin 2.3, tornando-se uma escolha viável para projetos de produção. A capacidade de compartilhar lógica de negócios entre plataformas reduz duplicação de código e facilita a manutenção. O padrão expect/actual permite definir interfaces comuns com implementações específicas por plataforma: ```kotlin // shared/src/commonMain/kotlin/com/app/network/ApiClient.kt import io.ktor.client.* import io.ktor.client.request.* import io.ktor.client.statement.* import kotlinx.serialization.Serializable import kotlinx.serialization.json.Json @Serializable data class UserProfile( val id: String, val displayName: String, val avatarUrl: String? ) // Expect/actual pattern for platform-specific HTTP engine expect fun createHttpClient(): HttpClient class ApiClient { private val client = createHttpClient() private val json = Json { ignoreUnknownKeys = true } // Suspend function shared across Android and iOS suspend fun fetchProfile(userId: String): UserProfile { val response = client.get("https://api.example.com/users/$userId") return json.decodeFromString(response.bodyAsText()) } } ``` A implementação específica para Android utiliza o OkHttp como engine HTTP, aproveitando suas otimizações para a plataforma: ```kotlin // shared/src/androidMain/kotlin/com/app/network/HttpClient.android.kt import io.ktor.client.* import io.ktor.client.engine.okhttp.* // Android uses OkHttp engine actual fun createHttpClient(): HttpClient = HttpClient(OkHttp) { engine { config { retryOnConnectionFailure(true) } } } ``` Em entrevistas técnicas, espera-se que candidatos compreendam as vantagens e limitações do KMP. Questões frequentes incluem cenários onde o compartilhamento de código é benéfico versus situações onde implementações nativas separadas são preferíveis. ## Parâmetros de Contexto: Mudanças na Resolução de Sobrecarga Os parâmetros de contexto receberam atualizações importantes no Kotlin 2.3.20 que afetam a resolução de sobrecarga. Funções com e sem parâmetros de contexto que possuem assinaturas similares agora geram erros de ambiguidade: ```kotlin // ContextParameters.kt class Logger { fun info(msg: String) = println("INFO: $msg") } class TransactionScope { fun execute(block: () -> Unit) = block() } // Function with context parameter context(logger: Logger) fun saveUser(id: Int) { logger.info("Saving user $id") } // Overload without context -- now ambiguous in 2.3.20 fun saveUser(id: Int) { println("Saving user $id (no logger)") } fun main() { val logger = Logger() // This now produces an ambiguity error in Kotlin 2.3.20 // context(logger) { saveUser(1) } // Fix: rename or qualify the context-aware variant } ``` Esta mudança força desenvolvedores a serem mais explícitos sobre qual versão da função deve ser chamada, melhorando a legibilidade e previsibilidade do código. ## Flows e Coroutines: Padrões Essenciais para Entrevistas O domínio de Flows e coroutines permanece como um dos tópicos mais avaliados em entrevistas para posições Android. A distinção entre Cold Flows e Hot Flows é fundamental: ```kotlin // FlowComparison.kt import kotlinx.coroutines.* import kotlinx.coroutines.flow.* // Cold Flow: emits only when collected fun userUpdates(): Flow = flow { println("Flow started") // Runs per collector emit("User logged in") delay(1000) emit("User updated profile") } // Hot Flow: emits independently of collectors class UserRepository { // StateFlow holds the latest value private val _state = MutableStateFlow("idle") val state: StateFlow = _state.asStateFlow() // SharedFlow broadcasts to multiple collectors private val _events = MutableSharedFlow() val events: SharedFlow = _events.asSharedFlow() suspend fun login() { _state.value = "loading" delay(500) _state.value = "authenticated" _events.emit("login_success") } } ``` Cold Flows executam seu bloco de código para cada coletor, enquanto Hot Flows emitem valores independentemente de haver coletores ativos. StateFlow mantém sempre o último valor emitido, enquanto SharedFlow pode ser configurado para diferentes políticas de replay. A integração correta com ViewModels é crucial para evitar vazamentos de memória e garantir que a coleta de dados respeite o ciclo de vida da UI: ```kotlin // UserViewModel.kt import androidx.lifecycle.ViewModel import androidx.lifecycle.viewModelScope import kotlinx.coroutines.flow.* import kotlinx.coroutines.launch class UserViewModel(private val repo: UserRepository) : ViewModel() { // Expose state to Compose UI val uiState: StateFlow = repo.state .stateIn( scope = viewModelScope, started = SharingStarted.WhileSubscribed(5000), initialValue = "idle" ) init { // Collect events safely within ViewModel scope viewModelScope.launch { repo.events.collect { event -> // Handle one-time events println("Event received: $event") } } } } ``` O uso de `SharingStarted.WhileSubscribed(5000)` permite que o Flow continue ativo por 5 segundos após o último coletor se desconectar, otimizando cenários de rotação de tela onde a recoleta imediata seria desnecessária. ## Modelagem de Estado com Sealed Interfaces Sealed interfaces fornecem uma forma type-safe de modelar estados de UI, garantindo que todos os casos sejam tratados em expressões when: ```kotlin // UiState.kt sealed interface UiState { data object Loading : UiState data class Success(val data: T) : UiState data class Error(val message: String, val retry: (() -> Unit)? = null) : UiState } // Usage in ViewModel fun loadUsers(): Flow>> = flow { emit(UiState.Loading) try { val users = apiClient.fetchUsers() emit(UiState.Success(users)) } catch (e: Exception) { emit(UiState.Error( message = e.localizedMessage ?: "Unknown error", retry = { /* trigger reload */ } )) } } ``` A inclusão de uma função de retry no estado de erro permite que a UI ofereça opções de recuperação sem acoplar a lógica de apresentação à lógica de negócios. ## Scope Functions: Uso Idiomático do Kotlin As scope functions do Kotlin (let, run, with, apply, also) são frequentemente avaliadas em entrevistas para verificar o domínio de padrões idiomáticos da linguagem: ```kotlin // ScopeFunctions.kt data class Request( var url: String = "", var method: String = "GET", var headers: MutableMap = mutableMapOf(), var body: String? = null ) fun buildRequest(): Request { // apply: configure an object, returns the object return Request().apply { url = "https://api.example.com/users" method = "POST" headers["Content-Type"] = "application/json" body = "{\"name\": \"Alice\"}" } } fun processNullable(input: String?) { // let: transform nullable, returns lambda result val length = input?.let { value -> println("Processing: $value") value.trim().length } ?: 0 // also: side effects, returns the original object input?.also { println("Logging input: $it") } // run: execute a block with receiver, returns lambda result val result = input?.run { // 'this' is the string uppercase().take(10) } } ``` A escolha da scope function correta depende de dois fatores: se o objeto deve ser referenciado como `this` ou `it`, e se o valor de retorno deve ser o próprio objeto ou o resultado do lambda. ## Null Safety: Práticas Recomendadas O sistema de tipos nullable do Kotlin é uma de suas maiores vantagens sobre Java, mas seu uso inadequado pode anular esses benefícios: ```kotlin // NullSafety.kt fun findUser(id: String): User? { // Returns null if user not found return database.queryUser(id) } // Bad: !! defeats the purpose of null safety fun riskyApproach(id: String) { val user = findUser(id)!! // NullPointerException if null println(user.username) } // Good: handle null explicitly fun safeApproach(id: String) { val user = findUser(id) ?: run { println("User not found") return } println(user.username) } // Good: provide default with Elvis operator fun displayName(id: String): String { return findUser(id)?.username ?: "Anonymous" } ``` O operador `!!` deve ser evitado em código de produção. Quando seu uso parece necessário, geralmente indica uma falha no design que permite estados inválidos. ## Perguntas Frequentes em Entrevistas sobre Kotlin 2.3 Entrevistadores em 2026 frequentemente exploram o conhecimento prático das novas funcionalidades do Kotlin 2.3. Algumas questões comuns incluem: **Sobre desestruturação baseada em nome:** Como a nova sintaxe com colchetes difere dos parênteses? Quando cada uma deve ser utilizada? **Sobre KMP:** Quais tipos de código são bons candidatos para compartilhamento entre plataformas? Quais devem permanecer específicos? **Sobre Flows:** Qual a diferença entre `collectAsState()` e `collectAsStateWithLifecycle()` no Jetpack Compose? **Sobre parâmetros de contexto:** Como resolver ambiguidades quando funções com e sem contexto possuem assinaturas similares? Candidatos bem preparados demonstram não apenas conhecimento teórico, mas capacidade de aplicar esses conceitos em cenários práticos de desenvolvimento. ## Conclusão O Kotlin 2.3 representa uma evolução significativa para o desenvolvimento Android, com funcionalidades que impactam diretamente a qualidade e manutenibilidade do código: - **Desestruturação baseada em nome** elimina uma classe inteira de bugs silenciosos, permitindo refatorações mais seguras - **Kotlin Multiplatform** atingiu maturidade para uso em produção, possibilitando compartilhamento eficiente de lógica de negócios - **Parâmetros de contexto refinados** forçam maior clareza na resolução de sobrecarga de funções - **Flows e coroutines** continuam sendo fundamentais para arquiteturas reativas modernas - **Sealed interfaces** fornecem modelagem type-safe de estados de UI - **Scope functions** e **null safety** permanecem como pilares do código Kotlin idiomático Profissionais que dominam esses conceitos e conseguem articulá-los claramente em entrevistas técnicas demonstram a profundidade de conhecimento esperada para posições de desenvolvimento Android em 2026. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/pt/blog/android/kotlin-2-3-interview-questions