Question 1

What is a mixin and why does Dart need them?

Accepted Answer

Open with one sentence: a mixin is the mechanism for sharing behaviour across several classes without building a hierarchy. Then explain the reason: Dart has single inheritance, so when unrelated classes need the same behaviour, extends cannot help. Take Duck, Fish and Submarine — no meaningful common superclass exists, yet all three swim. mixin Swimmer solves exactly that. Add the technical details: The on clause constrains the superclass and gives the mixin access to that type's members. A mixin also adds a type: duck is Swimmer is true, so a mixin doubles as an interface. A mixin has no constructor — the most important limitation. Finish with a concrete example: the core library's ListMixin turns two abstract members (length and operator []) into dozens of ready methods — the ideal shape of a mixin.

Question 2

What is linearization? What is the method lookup order for class C extends B with M1, M2?

Accepted Answer

Answer this one with a picture — draw the chain first, then explain it. Dart flattens mixin application into a linear chain: B ← B+M1 ← B+M1+M2 ← C Mixins apply left to right, each stacked on the previous one. Three consequences follow: 1. Lookup runs right to left: first C's own members, then M2, then M1, then B. So the last mixin wins. 2. Inside a mixin, super.method() goes leftwards — M2's super is M1, M1's super is B. That is what makes stackable behaviour possible: each mixin calls super and layers its own work on top. 3. Change the order and you change the result. with M1, M2 gives M2 -> M1 -> B; with M2, M1 gives M1 -> M2 -> B. To close strongly, add: it is precisely this linearity that means Dart has no diamond problem — every type appears exactly once in the lookup order. And state the practical consequence: if two mixins declare the same method, the compiler says nothing and the last one silently wins — a hard-to-find bug in a real codebase, which is why mixin member names should be specific and narrow.

Question 3

How do you choose between a mixin, inheritance and composition?

Accepted Answer

Decide by the relationship, then give practical signals. "X is a kind of Y" with a real taxonomy → extends. I keep it to one level; deep hierarchies make it hard to find where a method comes from. "X can also do Z" — the same behaviour repeating across unrelated classes → a mixin, with on requiring the context it needs. "X has a Z" — the behaviour needs configuration, must be swappable in tests, or must change at runtime → composition. I ask three questions to decide: Does it need a constructor parameter? (if yes, it cannot be a mixin) — Will I want to replace this with a fake in a test? (if yes, composition) — How many classes need this behaviour? (if one, write a method and stop). Close with an honest measure: a mixin looks cheap but creates hidden coupling — part of the class's behaviour lives in another file and the super chain hurts readability. So composition is my default, and a mixin is what I reach for when the duplication genuinely hurts.

Question 4

What is a mixin class and how does it differ from a plain mixin?

Accepted Answer

Before Dart 3, a type declared with the mixin keyword could only be used with with, while an ordinary class could be used with extends and (under some conditions) with with too. Dart 3 cleaned this up: an ordinary class can no longer be used as a mixin, and you declare the intent explicitly with mixin class. mixin class Timestamped { ... } works both ways: class A with Timestamped {} and class B extends Timestamped {}. The constraints: a mixin class must have no constructor (only the implicit default one) and cannot have an on clause — a superclass requirement would be meaningless when the type is extended. When do you need it? Mostly for backward compatibility: if a Dart 2-era library had a class used both with extends and with with, migrating to Dart 3 requires turning it into a mixin class. In new code it is rare — and a strong answer says so: a type should usually have one role, and a mixin class carries two, which blurs the API.

Question 5

What happens when two mixins declare the same method, and how do you manage that risk?

Accepted Answer

The answer has two halves: what happens, and what you do about it. What happens: the compiler reports neither an error nor a warning. By the linearization rule the mixin at the top of the chain — the last one — wins. If that mixin calls super.method(), the earlier version runs too and the results stack; if it does not, the earlier version silently disappears entirely. The second case is the dangerous one, because there is no signal at all. How I manage it: I give mixin members narrow, specific names: logRequest() rather than run(), cacheKey rather than key. I add a shared superclass or an on clause so @override becomes mandatory — then the intent is visible in the code. I keep internal helpers private with _; private members are library-scoped, which cuts collision risk sharply. If a class pulls in more than three or four mixins, I treat that as a design signal — it probably wants composition instead. One last sentence lands well: the order of mixins is part of the API — changing it casually changes behaviour, so it is worth justifying the order in a comment.

Approach	What it gives	When to pick it
Inheritance — `extends`	One parent, `super`, constructor chaining, an "is-a" relationship	When there is a real taxonomy (`Cat extends Animal`) and one level is enough
Mixin — `with`	Any number of hierarchy-free behaviours; a context requirement via `on`	When the same behaviour repeats across unrelated classes
Composition — hold it as a field	Full control, swappable dependency (a fake in tests), configuration	When the behaviour needs configuration or must change at runtime
`implements`	Contract only, zero implementation	When you only need type compatibility (fake, adapter)

Mixins

📚 Sources and documentation