Factory vs Builder Pattern Dart: When to Use Which
Factory and builder both create objects — so which one do you reach for? A decision guide with Dart code, a head-to-head table, and the named-constructor nuance nobody mentions.
*Last updated: October 8, 2026.* Factory decides WHAT to create. Builder controls HOW to build. That's the entire factory vs builder pattern Dart decision in two sentences: if your problem is choosing between several possible types at runtime, reach for a factory; if your problem is assembling one complicated object step by step, reach for a builder. The confusion exists because both patterns hide constructors — but they hide them for opposite reasons. This guide shows both in idiomatic Dart, compares them head-to-head, and gives you a verdict for the scenarios Flutter developers actually hit. The choice, stated plainly You're deciding between two different questions. "Which of these types should I get back?" is a factory question — the caller knows what it wants done, not which class does it. "How do I assemble this complicated thing without a 12-parameter constructor?" is a builder question — the caller knows exactly which type it wants, but configuring it is painful. Pick the pattern that matches your question and the code almost writes itself. Pick wrong and you get the classic symptoms: a builder with one fixed configuration, or a factory stuffed with optional parameters that should have been build steps. Symptoms you're holding the wrong one. You picked a factory but needed a builder when the factory method sprouts optional parameters — create({required type, color, padding, borderRadius, onTap}) is assembly wearing a selection costume, and every new option breaks every caller. You picked a builder but needed a factory when the builder has exactly one valid configuration, or when build() contains a switch returning different types — a builder that decides types is a factory with extra steps. The ugliest hybrid is the "configurable factory": a static…