Purpose of factory fromJson constructor in Dart models

WHAT THIS TESTS: This question checks whether you understand the semantic difference between generative and factory constructors in Dart, and more importantly whether you can articulate why deserialization logic should live inside the model rather than scattered across service layers. Interviewers want to see that you value separation of concerns and know when factory constructors offer flexibility that generative constructors cannot.

A GOOD ANSWER COVERS: A strong response hits four points in order. First, it explains that a factory constructor is not obligated to create a new instance every time; it can perform arbitrary logic and then return an existing instance, a subclass, or a newly constructed object. Second, it states that fromJson is simply a naming convention for a constructor that accepts a Map and produces a typed model, centralizing all JSON mapping in one place. Third, it highlights the practical reason factory is chosen: it lets you validate, transform, or supply defaults for raw JSON values before passing them to the generative constructor, which is especially useful when API types do not match your model types. Fourth, it notes that this pattern keeps the primary constructor clean and focused on field assignment while the factory handles the dirty work of parsing.

COMMON WRONG ANSWERS: Watch out for candidates who claim factory is the only way to deserialize JSON or that Dart requires it for fromJson methods. Another red flag is asserting that factory constructors automatically handle nested objects or lists without explicit mapping code. Some engineers confuse a factory constructor with a static method and cannot explain why the constructor syntax is idiomatic. Finally, claiming performance benefits without a specific scenario, such as instance caching, signals shallow understanding.

LIKELY FOLLOW-UPS: Expect the interviewer to push deeper with questions like these. How would you deserialize a JSON array into a List of this model? When would a static parse method be preferable to a factory constructor? How does sound null safety change the way you write fromJson? What happens when you introduce code generation tools like json_serializable or freezed?

ONE CONCRETE EXAMPLE: Imagine a Product model where the API returns price as a string but your class stores it as an int in cents. A factory Product.fromJson can parse the string, multiply by one hundred, and pass the computed int to the generative constructor. If the JSON omits a discount field, the factory can inject a default value of zero before instantiation. Without the factory, every network call site would need to duplicate that parsing and default logic.