Question 1

What is an extension method and how does it work?

Accepted Answer

Start with the definition, then give the mechanism — that is the part that separates answers. An extension adds methods, getters, setters and operators to an existing type without touching its source: extension StringX on String { bool get isBlank => trim().isEmpty; }. The mechanism: nothing is added to the class. The compiler rewrites value.isBlank into StringX(value).isBlank — a static function call. That single sentence explains all the behaviour: The call is resolved at compile time, from the static type. It does not work on dynamic, where the type is unknown at compile time. It cannot be overridden — you cannot override a static function. The extension must be in scope (imported). The type's own member always wins. Say where you actually use them: firstOrNull, isBlank, date formatting, adding a toDomain() to a model from someone else's package. A real example brings the answer to life.

Question 2

Animal a = dog; a.speak(); — what does an extension method print here, and why?

Accepted Answer

This is the classic trap of the topic. Build the answer in three steps. 1. The result: AnimalX.speak() runs — 'animal sound', not Dog's version, even though the object really is a Dog. 2. The reason: extensions are resolved at compile time from the variable's static type. The static type of a is Animal, so the compiler writes AnimalX.speak(a) right there during compilation. What the object turns out to be at runtime no longer matters. 3. The contrast: if speak() were an ordinary instance method, dynamic dispatch would run Dog's override. Always draw this contrast — it shows you understand the difference rather than having memorised a fact. Two extra nuances strengthen the answer: (a) explicit application bypasses static resolution — DogX(dog).speak(); (b) extensions are never found on dynamic, giving a NoSuchMethodError. State the practical consequence too: this is why extensions must not be used for polymorphic behaviour — when behaviour has to differ per variant, use an ordinary method, a sealed hierarchy, or an interface.

Question 3

When is an extension better than a plain utility function, and when is it worse?

Accepted Answer

The criterion is a single question: does it genuinely improve how the call site reads? Better: In a chain: users.where(...).firstOrNull — with a utility function you would write firstOrNull(users.where(...).toList()) and break the chain. When building domain vocabulary: 19999.asAzn, 3.days, '2026-01-01'.toDate(). When you need a method on a type you do not own — adding toDomain() to a model from someone else's package. Worse: When it hides a cost: a network call or heavy computation behind a getter makes the call site look like a field read, and it lies. Write an explicit Future<...> load() instead. When it piles names onto very general types (Object, int, String): every int in the project now answers to those names, autocomplete fills with noise, and the risk of a clash with another package rises. When polymorphism is required — extensions are never overridden, so they cannot express per-variant behaviour. When it is used in exactly one place — write a private function. Add a team-convention sentence: keep extensions in one file, name them narrowly (StringX, MoneyX), never extend Object, and avoid hidden asynchrony. That frames you as an engineer who thinks about design, not just syntax.

Question 4

What do you do when two packages define same-named extensions on the same type?

Accepted Answer

First state precisely what happens: the compiler does not choose for you, it reports an ambiguity error. That is actually good — an explicit error rather than a silent wrong call. Then list the three fixes and say which you prefer and why: 1. import 'b.dart' hide Trimmer; — hide one. Simple, but you lose all of that extension's members in the file. 2. import 'b.dart' show Squeezer; — bring in only what you need. It makes the intent of the import visible, so this is what I push for in a team. 3. Explicit application: Trimmer(value).squeeze(). The most precise route — no import gymnastics, and every call site shows which extension is running. It is also the only option when you need both in the same file. There is a fourth: an import 'b.dart' as b; prefix. But with a prefix an extension can only be invoked explicitly (b.Trimmer(value)) — knowing that shows attention to detail. Add a sentence on prevention: name extensions narrowly (MoneyFormatX rather than StringX), and avoid extending very general types in a public package — not creating the conflict beats resolving it.

Question 5

Can an extension reach private members, and how does it work with generic types?

Accepted Answer

Answer the two halves separately. Private members: privacy in Dart is at the library (file) level, not the class level. So an extension written in the same library has full access to _field; one in another library has none. The practical consequence: you cannot use an extension to reach into the internal state of a type from someone else's package — extensions work on the public API only. That is both a limitation and a safety guarantee. Generics: an extension can take its own type parameters, inferred from the on clause: extension ListX on List { T? get firstOrNull => isEmpty ? null : first; }. In [1,2,3].firstOrNull, T is inferred as int. The more interesting form is constraining with a bound: extension NumListX on List { T get total => ... }. Now the extension only appears on numeric lists and never pollutes autocomplete on List. This technique is genuinely useful in real projects and is rarely mentioned in interviews. One last nuance: the on clause accepts nullable types (on String?) and even types like on Future — extensions on Future are unexpectedly handy (something like future.timeoutOrNull(...)).

Question	Extension method	Ordinary instance method
When is it resolved?	At compile time, from the static type	At runtime, from the real type
Can it be overridden?	No	Yes
Does it work on `dynamic`?	No — a runtime `NoSuchMethodError`	Yes
Can it reach private fields?	Only within the same library	Yes
Does it depend on imports?	Yes — the extension must be in scope	No
On a clash with the type's own member	It loses — the type's own member wins	Not applicable

Extension methods

📚 Sources and documentation