Какие плюсы и минусы sealed-классов?

Плюсы и минусы Sealed-классов в Dart/Flutter

Sealed-классы (появились в Dart 3.0) — это мощный инструмент для создания типобезопасных иерархий и паттернов. Они решают проблемы обычного наследования и используются в pattern matching.

Что такое sealed-классы

Sealed-класс — это абстрактный класс, который может иметь только известное и ограниченное количество прямых подклассов. Все подклассы должны быть определены в одном файле или месте, что позволяет компилятору знать все возможные типы.

sealed class Result<T> {}

final class Success<T> extends Result<T> {
  final T data;
  Success(this.data);
}

final class Error extends Result<Never> {
  final String message;
  Error(this.message);
}

final class Loading extends Result<Never> {}

Плюсы sealed-классов

1. Полнота pattern matching

Компилятор требует обработать все возможные типы. Забыть вариант невозможно:

String getMessage(Result<int> result) {
  return switch(result) {
    Success(data: final value) => 'Got $value',
    Error(message: final msg) => 'Error: $msg',
    Loading() => 'Loading...',
    // Если забыть какой-то вариант — ошибка компиляции!
  };
}

2. Типобезопасность

Всегда знаешь, какие типы возможны. Нет неожиданных подклассов от сторонних пакетов.

sealed class ApiResponse<T> {}
// Никто не может создать свой подкласс извне — только Success, Error, Loading

3. Удобнее работать с вариантными типами

Ремонтируется повторяющийся код паттерна Result/Either. Вместо exception-based programming используем типы:

// Вместо try-catch можно использовать типы
final Result<User> userResult = await repository.getUser();
final name = userResult switch {
  Success(:final data) => data.name,
  Error(:final message) => 'Unknown',
};

4. Самодокументирующийся код

По sealed-классу сразу видно все возможные состояния и варианты. Не нужно искать подклассы по всему коду.

5. Улучшенная производительность pattern matching

Компилятор может оптимизировать switch-выражения, так как знает все возможные типы.

6. Предотвращение неправильного наследования

Нельзя случайно создать неправильный подкласс, так как наследование ограничено.

Минусы sealed-классов

1. Ограниченная гибкость

Все подклассы должны быть определены в одном месте (или нужно использовать специальные модификаторы доступа). Для плагинов и расширений это проблемно:

sealed class Plugin {}

// Другой файл/пакет
final class MyCustomPlugin extends Plugin {} // Ошибка! Нельзя наследоваться извне

2. Все подклассы должны быть final

Нельзя создавать подклассы подклассов без специальных хитростей. Это ограничивает иерархию.

3. Кривая обучения

Люди, привыкшие к обычному наследованию, могут быть запутаны sealed-классами и pattern matching'ом.

4. Boilerplate код

Для каждого подкласса нужно создавать final-класс или record. Иногда это может быть скучно:

sealed class State {}
final class LoadingState extends State {}
final class SuccessState extends State {
  final String data;
  SuccessState(this.data);
}
final class ErrorState extends State {
  final String error;
  ErrorState(this.error);
}
// Много кода для простых типов

5. Сложнее с генерик-типами

При работе с генериками иногда возникают сложности с типизацией:

sealed class Result<T> {}
final class Success<T> extends Result<T> {
  final T data;
  Success(this.data);
}

// Иногда нужно быть аккуратным с типизацией
Result<int> result = Success<int>(42);

6. Плохо для общей логики между вариантами

Если нужна общая функциональность для всех подклассов, это может быть неудобно реализовать без нарушения принципов.

Когда использовать sealed-классы

Используй sealed-классы когда:

• Есть конечное множество вариантов состояния (Result, Either, Option)
• Нужна полнота pattern matching
• Хочешь предотвратить неправильное расширение иерархии
• Работаешь с state management (BLoC, Riverpod)
• Разрабатываешь свою абстракцию, которая должна быть закрыта от расширения

Избегай sealed-классов когда:

• Нужна открытость для плагинов и расширений
• Иерархия постоянно растёт
• Работаешь с простыми классами, которые не нуждаются в pattern matching
• Коллеги не знакомы с pattern matching'ом

Пример в реальном приложении

sealed class AuthState {}

final class Unauthenticated extends AuthState {}

final class Authenticating extends AuthState {}

final class Authenticated extends AuthState {
  final User user;
  Authenticated(this.user);
}

final class AuthenticationError extends AuthState {
  final String message;
  AuthenticationError(this.message);
}

// В UI слое
Widget build(BuildContext context, AuthState state) {
  return state switch {
    Unauthenticated() => LoginScreen(),
    Authenticating() => LoadingScreen(),
    Authenticated(:final user) => HomeScreen(user: user),
    AuthenticationError(:final message) => ErrorScreen(message: message),
  };
}

Итог

Sealed-классы — отличный инструмент для моделирования конечных множеств типов и состояний. Они делают код безопаснее и явнее. Однако, как и все инструменты, нужно использовать их там, где они действительно полезны, а не везде подряд.