Question 1

What is an enhanced enum and how does it differ from the old one?

Accepted Answer

A short definition: since Dart 2.17 an enum is not just a list of names — it is a full type with fields, a const constructor, methods and getters, and it can implement interfaces and apply mixins. Then show the practical payoff, which is what makes the answer memorable. We used to write: int statusCode(Status s) { switch (s) { case Status.ok: return 200; ... } } Now that map lives inside the enum: ok(200, 'OK') plus final int code;. The data stays next to its type, the switch disappears, and adding a value means editing one place instead of three. List the limitations too — that shows depth: the constructor must be const (so no runtime-computed values), an enum cannot extends, cannot be generic, and must have at least one value. Those last two lead straight into the "enum or sealed?" question.

Question 2

Enum or sealed class? How do you decide?

Accepted Answer

Anchor the answer on one criterion, then add nuance: does each variant carry its own, different data? If not — it is just a list of names (Role, LogLevel, SortOrder) → enum. Lighter, values/name/byName come free, serialisation is easy, and the switch is exhaustiveness-checked. If yes — CardPayment(last4), TransferPayment(iban), CashPayment() → sealed class. Because every enum value shares the same field set, you could only fake this with nullable fields, which removes the "which field is set when" knowledge from the type system. Extra criteria: Need generics (Result<T>)? → sealed only; enums cannot be generic. Is serialisation to a database or API the priority? → the enum is cheaper. Need different behaviour per variant? Both can do it: a method on the enum, an override in the sealed hierarchy. Highlight the shared benefit: a closed set plus a default-less switch means a forgotten variant is a compile-time error. That sentence rounds the answer off and shows you know why the question was asked.

Question 3

How do you serialise an enum value to an API and to a database?

Accepted Answer

This question tests real experience — make sure you hit the index trap. Writing: never store index. Give the concrete reason: index depends on declaration order, so the day someone sorts the values alphabetically or inserts a value in the middle, every stored row reads back wrong — with no compile error anywhere. Store name, or better, put an explicit code field in the enum: admin('ADMIN'). An explicit code also lets you rename the Dart-side value freely. Reading: byName throws, so I never hand it external data. The correct shape: static Role parse(String? raw) => Role.values.asNameMap()[raw] ?? Role.unknown; And I deliberately add an unknown value to the enum. Explain why: a mobile app sits in the store on an old version for months while the backend adds a new status — without unknown the app crashes during parsing. That forward-compatibility argument lifts the answer to senior level. If you use json_serializable, the @JsonValue('ADMIN') annotation code-generates the same thing — worth mentioning, though the principle is unchanged.

Question 4

Why is writing default in a switch over an enum harmful?

Accepted Answer

Start with the mechanism: because an enum's value set is closed, the compiler can check whether the switch covers every variant. Once all values are listed, default is not merely redundant — it is harmful, because it turns the exhaustiveness check off. Then show the consequence with a concrete scenario: someone adds refunded to OrderStatus. Without default, the compiler hands you the list of every switch and forces a decision at each one. With default, the code compiles silently and refunded orders fall into the "unknown status" branch — the bug is found in production. Give one exception so the answer does not sound dogmatic: default makes sense when handling a value that comes from outside, but even there the right place is the parse function — adding an unknown value to the enum and keeping the switch exhaustive is better. A final nuance: a switch expression (rather than a statement) requires every branch to produce a value, which tightens exhaustiveness further — that is my default choice.

Question 5

When is adding methods or a mixin to an enum a good design decision, and when is it not?

Accepted Answer

The dividing criterion: does the method follow from the enum's own nature, or from an external context? Good use — the method depends only on the enum's own fields: HttpStatus.isError => code >= 400, LogLevel.isAtLeast(other), Direction.opposite. That keeps the data next to its type, removes switch statements, and forces the compiler to demand the fields when a value is added. Bad use — the enum gets coupled to an outer layer. The most common case: storing UI text, colours or localisation keys inside the enum. Your domain enum now depends on the presentation layer, it is harder to test, and the same enum cannot be reused in a different context (a backend job, say). Such maps belong in a separate extension or a Map in the presentation layer. On mixins: an enum can implements and with — implementing Comparable, for example, is entirely normal. But a mixin cannot hold mutable state here (enum values are const), so its role is purely behaviour sharing. Finish with a practical rule: every member I add to an enum must pass the question "does this belong to the value itself, or to the place that uses it?" If it is the latter, write an extension.

Member	What it gives	Watch out
`Role.values`	A `List` of all values, in declaration order	It is unmodifiable; use it freely with `where` and `map`
`role.name`	The value's name as a `String` — `'admin'`	`toString()` gives `'Role.admin'` instead — use `name` for serialisation
`role.index`	The zero-based ordinal position	Never persist it — reordering the values corrupts stored data
`Role.values.byName('admin')`	Looks a value up by name	Throws ArgumentError when not found — never feed it raw external data
`Role.values.asNameMap()`	A `Map<String, Role>` for safe lookups	`asNameMap()[raw]` returns `null` instead of throwing
`compareTo`	By default comparison is by `index` (via helpers; `Enum` itself is not `Comparable`)	Implement `Comparable` when you need a domain ordering

Enhanced enums

📚 Sources and documentation