Composition Over Inheritance in Android ViewModels: Stop Writing BaseViewModel

How Kotlin interface delegation and Lifecycle 2.11 scoping replace bloated 500-line base classes.

Almost every mature Android codebase has a file called BaseViewModel.kt.

It always starts with good intentions. Someone wants to avoid repeating MutableSharedFlow boilerplate for one-off snackbar events or loading spinners, so they create a small abstract class.

Eighteen months later, BaseViewModel is 600 lines long. It handles network connectivity checks, analytics tracking, error dialogs, pagination state, and session logout. Every single screen in the app inherits from it—even a static "About Us" screen that only needs two strings.

Worse, when a screen needs two subset behaviors (say, PaginatedViewModel AND SearchableViewModel), single inheritance hits a brick wall. You end up stuffing both into the root BaseViewModel, turning every unit test in your project into a mocking nightmare.

Here is how modern Kotlin teams in 2026 are deleting BaseViewModel completely using Kotlin interface delegation (by) and composable state holders.

1. The Anti-Pattern: The “God” BaseViewModel