Question 1

What is a factory constructor and when do you reach for one?

Accepted Answer

Start from the difference: a generative constructor must create a new instance, while a factory is only obliged to return something of a compatible type. That is why a factory has no this, cannot have an initializer list, and cannot be const. Then name three real scenarios: JSON parsing — factory User.fromJson(Map<String, dynamic> json): here you can validate, throw, and even inspect a type field and return AdminUser or GuestUser. A generative constructor cannot do that. Cache / flyweight — avoid rebuilding an object for the same currency code, the same icon, the same config. Singleton — factory Logger() => _instance;. Close with the limitation: because a factory is never const, such a class cannot be used in a const context — a genuine design trade-off when writing a Flutter widget.

Question 2

What is an initializer list and when can you not do without it?

Accepted Answer

The initializer list is the part that starts with : after the constructor signature and runs before the body. It is mandatory in three cases: 1. Filling a final field with a computed value: Temperature.fahrenheit(double f) : celsius = (f - 32) * 5 / 9; — you cannot assign to a final in the body. 2. Passing a computed argument to super(...). 3. Validating input with assert(...) before the object exists. Finish with the execution order — that is the detail that satisfies an interviewer: initializer list → super constructor → body. Then draw the logical consequence: this is unusable in the initializer list, because the object is not there yet. For a plain constant value you do not need an initializer list at all — the this.x shorthand or a field-level initializer reads better.

Question 3

What is a const constructor for, and how does it affect Flutter performance?

Accepted Answer

Answer on two levels. Language level: a const constructor builds the object at compile time and canonicalises it — the same type with the same constant arguments always means one single object, so identical(const Padding(8,8), const Padding(8,8)) is true. The conditions: all fields final, empty body, only constants in the initializer list. Flutter level: the widget tree is rebuilt on every frame that touches it. If a subtree is a const widget, that object is never recreated — the framework sees the old and new references are identical and skips that subtree's build entirely. So the win is twofold: no allocation and no rebuild. That is why prefer_const_constructors and prefer_const_literals_to_create_immutables are enabled in nearly every Flutter project. A strong answer ends on a nuance: a class with a const constructor can still be invoked without const, and then you gain nothing. Making the constructor const is not enough — the call site has to say const too.

Question 4

What is the difference between a redirecting constructor and a factory constructor?

Accepted Answer

Both look like "pass the work to someone else", but the difference is fundamental. Redirecting (Order.empty() : this('');) — forwards to another generative constructor of the same class. It has no body, no other initializers, always ends up creating a new object, and can be const. The purpose: remove duplicated default values. Factory — is not obliged to forward at all: it can have a full body, check conditions, look in a cache, return a subtype or an already existing object. It can never be const. There is also a redirecting factory written as factory Foo = Bar;, which forwards construction to a completely different class — the idiom used to give an abstract class a default implementation (the abstract class Set { factory Set() = LinkedHashSet; } style). Knowing that detail lifts the answer above the expected level.

Question 5

How would you design an immutable model class?

Accepted Answer

Give a concrete recipe, not theory: All fields final, the constructor const — the object becomes immutable and usable in const contexts at once. Use named parameters with required: const User({required this.id, required this.name}); — positional parameters become unreadable in a five- or six-field model. Write a copyWith — a modified copy instead of mutation. Know the nuance too: a naive copyWith cannot set a field to null (because null means "leave unchanged"); when you need that you use a sentinel value or an Object? wrapper. Override == and hashCode (or reach for equatable / freezed) — otherwise two equal-valued objects are not equal, and caching, Set membership and comparison logic all break. Wrap collection fields with List.unmodifiable — a final List field freezes the reference, not the contents. Add one Flutter sentence: immutability makes state comparison cheap — you can compare old and new state with == and skip an unnecessary rebuild.

Constructor kind	Creates a new object?	Typical use
Generative — `Order(this.id)`	Yes, always	Plain data classes and models
Named — `Order.draft()`	Yes	Alternative construction scenarios (the overload substitute)
Redirecting — `Order.empty() : this('')`	Yes (through another constructor)	Keeping default values in one place
Factory — `factory Order.fromJson(...)`	No — may return a cache entry, a singleton, or a subtype	JSON parsing, caching, singletons, choosing a subtype
Const — `const Point(this.x, this.y)`	Once at compile time, then reused	Immutable value objects

Constructors

📚 Sources and documentation