SOLID on Android

Architecture and dependency injection Mid-level Kotlin 2.0+ API 24+ Reviewed 31 Oct 2026 By Best Latest Apps

Pick the fix

A PaymentProcessor has a growing when (method) with card, PayPal and Google Pay branches, each with a lot of code. Adding a method keeps breaking others. Best change?

OptionsGive each method its own implementation of a PaymentMethod interfaceAdd comments separating the branchesMove the when into the ViewModelUse reflection to call methods by name

Hint 1 of 1

How can you add a method without editing the others?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Give each method its own implementation of a PaymentMethod interface

Correct. New methods are new classes; existing ones aren't touched.

Why not the others?

B Add comments separating the branches. Doesn't reduce coupling.
C Move the when into the ViewModel. Moves the problem up.
D Use reflection to call methods by name. Loses type safety.

30-second answer

Single responsibility: a ViewModel shapes one screen's state, a repository owns one kind of data. Open/closed: add a new payment method as a new implementation, not by editing a big when. Liskov: fakes must behave like the real thing. Interface segregation: small interfaces like ArticleReader instead of one giant repository. Dependency inversion: ViewModels depend on interfaces that DI binds.

Practise saying it · 40 s. No recording, just a timer

Explain SOLID with Android examples.

Say your answer out loud, then check which of these points you covered:

One responsibility per class
Extend with new implementations
Fakes behave like the real thing
Small interfaces
Depend on abstractions via DI

Deep dive

Don't apply them mechanically; small apps need fewer abstractions.

Interfaces are most useful at boundaries you'll swap: network, storage, clock, analytics.

A fake that throws where the real one returns empty breaks Liskov and hides bugs.

Sealed types plus exhaustive when can be fine; open/closed is about the cost of change.

Common mistakes

An interface for every class with one implementation forever.
God ViewModels that load, format, navigate and log.
Fakes that don't behave like the real implementation.

Senior take & follow-ups

Give one concrete Android example per letter, briefly; skip the textbook definitions.

Follow-up questions

Think of your answer first, then open the hint.

Where are interfaces most valuable?
Show hint
At boundaries you'll replace in tests or swap later.
Is a when over sealed types an open/closed violation?
Show hint
Not necessarily; the compiler flags every place to update.

Suggest a fix if something here is wrong or out of date.