Flutter und Dart 3: Records, Patterns und fortgeschrittene Interview-Fragen

Dart 3 Records, Patterns und Sealed Classes bilden das Fundament moderner Flutter-Entwicklung im Jahr 2026. Diese drei Features, eingeführt in Dart 3.0 und verfeinert bis Dart 3.11, ermöglichen algebraische Datentypen, exhaustives Pattern Matching und Compile-Time-Sicherheit, die ganze Kategorien von Fehlern bereits vor der Laufzeit erkennt.

Dart 3 Records: Leichtgewichtige Datenaggregation

Records lösen ein langjähriges Problem in Dart: die Rückgabe mehrerer Werte aus einer Funktion, ohne eine dedizierte Klasse erstellen zu müssen. Ein Record ist ein anonymer, unveränderlicher, aggregierter Typ.

// Returning multiple values with a positional record
(String, int) parseUserInput(String raw) {
  final parts = raw.split(':');
  return (parts[0].trim(), int.parse(parts[1]));
}

// Named fields improve readability for complex returns
({String name, String email, bool isVerified}) fetchUserProfile(String id) {
  // Simulated database lookup
  return (
    name: 'Alice Chen',
    email: 'alice@example.com',
    isVerified: true,
  );
}

Records sind strukturell typisiert: Zwei Records mit denselben Feldtypen und -namen sind derselbe Typ. Dies eliminiert die Notwendigkeit für Tuple2, Pair oder ähnliche Hilfsklassen, auf die Flutter-Entwickler vor Dart 3 angewiesen waren.

// Structural equality — no need for custom == operator
void main() {
  final a = (1, 'hello');
  final b = (1, 'hello');
  print(a == b); // true — records compare by value

  // Named fields also support equality
  final profile1 = (name: 'Alice', role: 'admin');
  final profile2 = (name: 'Alice', role: 'admin');
  print(profile1 == profile2); // true
}

Records eignen sich am besten für Funktionsrückgaben, lokale Aggregation und Map-Keys. Für Domänenmodelle mit Methoden und Validierung bleiben Klassen die richtige Wahl.

Dart Pattern Matching: Destrukturierung und Kontrollfluss

Pattern Matching in Dart 3 geht weit über einfache Typprüfungen hinaus. Patterns destrukturieren Werte, binden Variablen und steuern den Kontrollfluss — alles in einem einzigen Ausdruck.

// Destructuring a record with pattern matching
void main() {
  final (name, email, isVerified) = fetchUserProfile('u-123');
  // name, email, isVerified are now local variables

  // List patterns with rest operator
  final scores = [98, 87, 92, 76, 84];
  final [first, second, ...remaining] = scores;
  print('Top two: $first, $second'); // 98, 87
  print('Others: $remaining');        // [92, 76, 84]
}

Switch-Ausdrücke, kombiniert mit Patterns, ersetzen ausführliche if-else-Ketten durch prägnantes, exhaustives Matching:

// Switch expression with guard clauses
String classifyScore(int score) => switch (score) {
  >= 90 => 'Excellent',
  >= 80 => 'Good',
  >= 70 => 'Average',
  >= 60 => 'Below Average',
  _ => 'Needs Improvement',
};

// Object pattern matching with type checking
String describeValue(Object value) => switch (value) {
  int n when n < 0   => 'Negative integer: $n',
  int n              => 'Positive integer: $n',
  String s when s.isEmpty => 'Empty string',
  String s           => 'String of length ${s.length}',
  List l when l.isEmpty  => 'Empty list',
  List l             => 'List with ${l.length} elements',
  _                  => 'Unknown type',
};

Guard-Klauseln (das Schlüsselwort when) fügen Patterns bedingte Logik hinzu, ohne Verschachtelung. Dies hält Switch-Ausdrücke flach und lesbar.

Sealed Classes: Exhaustive Zustandsmodellierung

Sealed Classes beschränken ihre Subtyp-Hierarchie auf dieselbe Datei und ermöglichen es dem Dart-Compiler zu überprüfen, dass jeder Subtyp in einem Switch behandelt wird. Dies ist das entscheidende Element für typsichere Zustandsverwaltung.

// Sealed class defining all possible authentication states
sealed class AuthState {}

class AuthInitial extends AuthState {}

class AuthLoading extends AuthState {}

class AuthAuthenticated extends AuthState {
  final String userId;
  final String displayName;
  AuthAuthenticated({required this.userId, required this.displayName});
}

class AuthError extends AuthState {
  final String message;
  final int? statusCode;
  AuthError({required this.message, this.statusCode});
}

Der Compiler erzwingt Exhaustiveness — jede Unterklasse muss behandelt werden:

// Exhaustive switch — compiler error if a case is missing
Widget buildAuthUI(AuthState state) => switch (state) {
  AuthInitial()       => const LoginPrompt(),
  AuthLoading()       => const CircularProgressIndicator(),
  AuthAuthenticated(
    displayName: final name
  )                   => Text('Welcome, $name'),
  AuthError(
    message: final msg,
    statusCode: final code,
  )                   => ErrorBanner(
    message: msg,
    code: code,
  ),
};

Das Hinzufügen eines neuen AuthState-Subtyps (z.B. AuthSessionExpired) erzeugt sofort Compile-Time-Fehler an jeder Stelle, die AuthState behandelt. Dies eliminiert das Risiko vergessener Zustandsbehandlung — eine häufige Fehlerquelle in Flutter-Apps mit string- oder enum-basiertem Zustand.

Records, Patterns und Sealed Classes in der Praxis kombinieren

Die eigentliche Stärke zeigt sich, wenn diese drei Features zusammenarbeiten. Ein bewährtes Muster für Flutter-API-Aufrufe kombiniert Sealed Classes für Ergebnistypen mit Records für strukturierte Daten:

// Generic sealed result type for API operations
sealed class ApiResult<T> {}

class ApiSuccess<T> extends ApiResult<T> {
  final T data;
  final ({int statusCode, Map<String, String> headers}) metadata;
  ApiSuccess(this.data, {required this.metadata});
}

class ApiFailure<T> extends ApiResult<T> {
  final String error;
  final int? statusCode;
  ApiFailure(this.error, {this.statusCode});
}

// Consuming the sealed result with pattern matching
Widget buildProductList(ApiResult<List<Product>> result) => switch (result) {
  ApiSuccess(
    data: final products,
    metadata: (statusCode: 200, headers: _),
  ) when products.isNotEmpty => ListView.builder(
    itemCount: products.length,
    itemBuilder: (_, i) => ProductCard(products[i]),
  ),
  ApiSuccess(data: final products) when products.isEmpty =>
    const EmptyState(message: 'No products found'),
  ApiFailure(statusCode: 401) =>
    const AuthExpiredBanner(),
  ApiFailure(error: final msg) =>
    ErrorDisplay(message: msg),
};

Dieses Muster eliminiert Null-Checks, Type-Casts und Laufzeit-Assertions. Jeder mögliche Zustand wird zur Compile-Time berücksichtigt.

Fortgeschrittene Interview-Fragen zu Dart 3 Features

Technische Interviews für Flutter-Positionen im Jahr 2026 testen zunehmend das Verständnis der Dart 3-Sprachfeatures. Im Folgenden finden sich Fragen, die über die reine Syntax hinausgehen und architektonisches Denken prüfen.

F: Wie unterscheiden sich Records von Klassen bei der Datenmodellierung?

Records sind strukturell typisiert, unveränderlich und anonym. Zwei Records mit identischen Feldtypen sind derselbe Typ. Klassen sind nominal typisiert — zwei Klassen mit identischen Feldern sind unterschiedliche Typen. Records eignen sich für Funktionsrückgaben, lokale Aggregation und Map-Keys. Klassen eignen sich für Domänenmodelle, die Methoden, Validierung oder Identität erfordern.

F: Wann ist eine Sealed-Class-Hierarchie einem Enum vorzuziehen?

Enums tragen keine variantenspezifischen Daten. Sealed Classes erlauben es jedem Subtyp, unterschiedliche Felder zu besitzen. Beispielsweise trägt AuthAuthenticated eine userId, während AuthError message und statusCode enthält. Enums können dies nicht modellieren. Sealed Classes unterstützen zudem tiefes Pattern Matching auf ihren Feldern, nicht nur auf dem Variantennamen.

F: Was passiert zur Compile-Time, wenn ein neuer Subtyp zu einer Sealed Class hinzugefügt wird?

Der Dart-Analyzer kennzeichnet sofort jeden Switch-Ausdruck oder jede Switch-Anweisung, die diesen Sealed-Typ behandelt, als nicht-exhaustiv. Der Code kompiliert nicht, bis der neue Fall überall behandelt wird. Diese Compile-Time-Garantie ist der Hauptvorteil gegenüber abstrakten Klassen, die keine Exhaustiveness-Prüfung bieten.

F: Wie verbessert Pattern Matching die Null-Sicherheit in der Praxis?

Patterns ermöglichen prägnante Null-Prüfungen durch if-case:

// If-case for null-safe extraction
void processUser(Map<String, dynamic> json) {
  if (json case {'name': String name, 'age': int age}) {
    // name and age are non-nullable here
    print('$name is $age years old');
  } else {
    print('Invalid user data');
  }
}

Das Pattern validiert gleichzeitig die Map-Struktur, prüft Typen und bindet nicht-nullable Variablen. Ohne Patterns erfordert dies verschachtelte Null-Checks und manuelle Type-Casts.

F: Erklären Sie den Unterschied zwischen _ in Patterns und _ als Wildcard-Variable (Dart 3.7+).

Vor Dart 3.7 war _ nur innerhalb von Patterns ein Wildcard — var [_, _, third] = list funktionierte, weil Pattern-_ niemals bindet. Außerhalb von Patterns war _ ein regulärer Variablenname. Dart 3.7 vereinheitlichte dies: _ ist nun überall nicht-bindend, einschließlich Funktionsparametern und lokalen Variablen. Mehrere _-Deklarationen im selben Scope erzeugen keine Konflikte mehr.

Migrationsstrategie: Dart 3 Features in bestehenden Flutter-Apps einführen

Die Migration einer bestehenden Flutter-Codebasis zu Dart 3 Patterns kann inkrementell erfolgen. Der Beginn sollte bei den Änderungen mit dem höchsten Mehrwert liegen.

Schritt 1 — Tuple/Pair-Typen durch Records ersetzen. Nach Tuple2, Pair oder benutzerdefinierten Zwei-Feld-Klassen suchen, die ausschließlich zum Bündeln von Rückgabewerten verwendet werden. Der Ersatz durch Records führt zu sofortiger Code-Reduktion.

Schritt 2 — If-else-Typprüfungen in Switch-Ausdrücke umwandeln. Jede Kette von if (value is TypeA) ... else if (value is TypeB) wird zu einem Switch-Ausdruck mit Pattern Matching. Dies gilt besonders für Widget-Erstellung und Zustandsbehandlung.

Schritt 3 — Zustandshierarchien versiegeln. Für BLoC-States, Riverpod-Notifier-States oder benutzerdefinierte Zustandsklassen den sealed-Modifizierer hinzufügen. Der Compiler identifiziert dann jede Stelle, an der die Zustandsbehandlung unvollständig ist.

Schritt 4 — Guard-Klauseln in Switches einsetzen. if-Prüfungen innerhalb von Case-Bodies durch when-Guards ersetzen, für flacheren, besser lesbaren Kontrollfluss.

Jeder Schritt ist unabhängig wertvoll und erfordert nicht die Modifikation der gesamten Codebasis auf einmal.

Fazit

• Records eliminieren Boilerplate für Multi-Value-Rückgaben — sie ersetzen Tuple, Pair oder Einzweck-Klassen
• Pattern Matching ersetzt if-else-Typprüfungsketten durch exhaustive, compiler-verifizierte Switch-Ausdrücke
• Sealed Classes garantieren, dass jede Zustandsvariante behandelt wird, und verwandeln Laufzeitfehler in Compile-Time-Fehler
• Guard-Klauseln (when) halten Switch-Ausdrücke flach und eliminieren verschachtelte Bedingungen innerhalb von Case-Bodies
• Dart 3.7 Wildcard-Variablen (_) vereinheitlichen das nicht-bindende Verhalten von Patterns mit regulären Parametern und lokalen Variablen
• Die Migration kann inkrementell erfolgen: mit Records für Funktionsrückgaben beginnen, dann Typprüfungen in Switches umwandeln, dann Zustandshierarchien versiegeln
• Diese Features werden aktiv in Flutter-Fachinterviews geprüft — das Verständnis des "Warum" ist ebenso wichtig wie die Syntax