Question 1

Explain the difference between extends, implements and with.

Accepted Answer

Separate all three in one sentence, then expand: extends inherits the implementation, implements takes only the contract, with attaches implementation without building a hierarchy. The details: extends — exactly one, super.method() works, constructors chain. It expresses "X is a kind of Y". implements — as many as you like; nothing is inherited, you write every member. The key Dart nuance: every class defines an implicit interface, so implements PaymentGateway works on a concrete class too — the cheapest way to build a fake in a test. with — as many as you like, implementation comes along; mixins are linearized and form a super chain. End with a practical rule: to share behaviour use a mixin or composition, for a type contract use implements, and for a genuine "is-a" relationship use extends.

Question 2

Why were class modifiers added in Dart 3, and when do you pick which?

Accepted Answer

Start from the reason: in Dart 2 every class could be both extended and implemented. For a package author that meant adding a method to a class was a breaking change — anyone implementing it broke. Modifiers put that decision back in the author's hands. Then walk the selection table: final — nobody may extend or implement. My default in a package, because loosening it later is easy while tightening it is breaking. interface — implement only; I give a contract, not my implementation. base — extend only; guarantees every instance carries my state and invariants. It is contagious: subtypes must be base/final/sealed too. sealed — a closed set of variants, exhaustive switching. mixin class — a type usable both with with and with extends. Wrap up: inside application code you usually need no modifier at all; modifiers are primarily a tool for the library boundary. That last sentence makes the answer look balanced.

Question 3

How would you use a sealed class with exhaustive switching in a real scenario?

Accepted Answer

Pick a concrete scenario — screen state or a network result is the best. sealed class LoadState<T> with three subtypes: Loading, Success(data), Failure(error). Then I handle every variant with a switch expression (not a statement): switch (state) { Loading() => ..., Success(:final data) => ..., Failure(:final error) => ... }. I deliberately write no default. Explain the payoff in two beats: 1. The moment someone adds a new variant (Empty), every switch stops compiling and the compiler hands over the list of places to fix. The "we forgot to handle this state" class of bug never reaches runtime. 2. Pattern matching gives destructuring for free: Success(:final data) reaches the payload directly, with no as cast and no is check. A when clause lets you add a refined branch. If they ask about Flutter, one sentence is enough: the pattern lets you record every possible UI state in the type system. Add a caveat: if the variant count grows large (10+), a sealed hierarchy gets heavy and splitting it into smaller state types is better.

Question 4

What is the difference between a sealed and a final class?

Accepted Answer

The shallow answer is "both restrict subtyping" — and that is the most common mistake. Draw the line precisely: final class — extending/implementing is forbidden from outside, but inside the same library there may be any number of subtypes and the compiler does not track that set. The class itself is instantiable. sealed class — implicitly abstract (not instantiable) and implicitly final. On top of that it tells the compiler all direct subtypes live in this library, and the compiler uses that set for exhaustiveness checking. So the core difference: final merely closes the type; sealed closes it and hands the compiler the complete variant set. The practical consequence: you can write a default-less switch over a sealed type, but not over a final one. Add one nuance: sealed does not combine with other modifiers (there is no sealed final) because it already implies both. The subtypes, though, are usually declared final — so the variant set is closed and no variant can be extended from outside either.

Question 5

Have you used the base modifier? When is it the right choice?

Accepted Answer

An honest structure: first explain what problem it solves, then give an example from your own work (and if you have none, say plainly that application code did not need it — that is not a weakness). base guarantees one thing: every instance of this type carries my real implementation, because from outside only extends is possible, never implements. That matters when the class's methods depend on each other or maintain an internal invariant — say one method fills _cache and another reads it. If someone implements the class, that internal wiring is gone and there is no guarantee your close() is ever called. Be sure to mention the contagion: every subtype of a base class must itself be base, final or sealed. That is deliberate — no one may open a hole in the chain with implements. The practical consequence: base pushes cost onto the consumer (building test fakes gets harder, and packages like mocktail rely on implements), so I pick it only when a real invariant needs protecting — otherwise final or a plain class is the better deal.

Modifier	Allowed OUTSIDE the library	What it is for
`class` (no modifier)	new, extends, implements	The Dart 2 behaviour — most permissive, least protected
`abstract class`	extends, implements (no new)	An incomplete type that cannot be instantiated directly
`base class`	extends only; subtypes must themselves be base/final/sealed	Guarantees every instance carries your implementation
`interface class`	implements only	Hand out a contract without handing out the implementation
`final class`	neither extends nor implements — use only	Freedom to add members later without a breaking change
`sealed class`	nothing (implicitly abstract + final)	The full set of subtypes is known — exhaustive switch
`mixin class`	extends, implements and `with`	A type usable both as a class and as a mixin

Class modifiers

📚 Sources and documentation