ホーム
Flutter
【2025年最新】Flutter状態管理完全ガイド：Provider、Riverpod、BLoCの使い分けと実装例

【2025年最新】Flutter状態管理完全ガイド：Provider、Riverpod、BLoCの使い分けと実装例

3 May, 2025

Flutter状態管理の基本：なぜ適切な状態管理が重要なのか

なぜFlutterで状態管理が重要なのか

Flutterアプリ開発において、状態管理は成功の鍵を握る重要な要素です。アプリの「状態」とは、ユーザーインターフェースに表示されるデータや、ユーザーとのインタラクションによって変化する情報のことを指します。例えば、ログイン情報、買い物かごの中身、ダークモード設定など、アプリ内で変化するあらゆるデータが状態に含まれます。

Flutter状態管理の基本：なぜ適切な状態管理が重要なのか
なぜFlutterで状態管理が重要なのか
StatefulWidgetの限界とグローバル状態管理の必要性
Flutterにおける主要な状態管理手法の概要
Providerを使った状態管理：シンプルで効率的なアプローチ
Provider基礎：セットアップと基本的な使い方
ChangeNotifierProviderを使った実装例
Providerのメリットと適した使用シーン
実践的なFlutter状態管理ベストプラクティス
テスト容易性を考慮した状態管理設計
パフォーマンス最適化のための考慮点
保守性の高い状態管理コードの書き方
まとめ：状態管理手法の使い分けとベストプラクティス

Tasuke Hub管理人

東証プライム市場上場企業エンジニア

情報系修士卒業後、大手IT企業にてフルスタックエンジニアとして活躍。 Webアプリケーション開発からクラウドインフラ構築まで幅広い技術に精通し、複数のプロジェクトでリードエンジニアを担当。技術ブログやオープンソースへの貢献を通じて、日本のIT技術コミュニティに積極的に関わっている。

🎓情報系修士🏢東証プライム上場企業💻フルスタックエンジニア📝技術ブログ執筆者

適切な状態管理フレームワークを選択することで、以下のような多くのメリットが得られます：

// 状態管理なしの例 - コードが複雑になりがち
class CounterScreen extends StatefulWidget {
  @override
  _CounterScreenState createState() => _CounterScreenState();
}

class _CounterScreenState extends State<CounterScreen> {
  int _counter = 0;
  
  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }
  
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Text('$_counter'),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        child: Icon(Icons.add),
      ),
    );
  }
}

コードの整理と保守性の向上: 適切な状態管理により、UIとビジネスロジックを分離できます。これにより、コードが整理され、チーム開発やメンテナンスが容易になります。
アプリのパフォーマンス向上: 効率的な状態管理は不要な再描画を減らし、アプリのパフォーマンスを向上させます。特に複雑なUIや大量のデータを扱うアプリでは、適切な状態管理が必須です。
バグの減少: 状態の変更を一元管理することでバグの追跡が容易になり、予測可能な動作を実現できます。
スケーラビリティ: アプリの規模が大きくなるにつれて、ローカルな状態管理だけでは対応しきれなくなります。適切な状態管理フレームワークを使用することで、アプリの成長に合わせてスケールすることが可能になります。

「綺麗なコードとは、読む人の時間を節約するコードである」というBjarne Stroustrupの言葉がありますが、適切な状態管理はまさにそれを実現する重要な手段なのです。

StatefulWidgetの限界とグローバル状態管理の必要性

Flutterの基本的な状態管理手法として、StatefulWidgetとsetState()メソッドがあります。これらは簡単な状態管理には適していますが、アプリが複雑になるにつれて以下のような限界が見えてきます：

状態の局所性: StatefulWidgetの状態はそのウィジェットとその子ウィジェットでしか利用できません。離れたウィジェット間でデータを共有する場合、状態を上位のウィジェットに持ち上げる必要があります。

// 状態の共有のために上位ウィジェットに状態を持ち上げる例
class ParentWidget extends StatefulWidget {
  @override
  _ParentWidgetState createState() => _ParentWidgetState();
}

class _ParentWidgetState extends State<ParentWidget> {
  int count = 0;
  
  void incrementCount() {
    setState(() {
      count++;
    });
  }
  
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        ChildWidget1(count: count),
        ChildWidget2(onPressed: incrementCount),
      ],
    );
  }
}

コールバック地獄: 深いウィジェットツリーでは、状態を更新するためのコールバック関数を何層もの子ウィジェットに渡す必要があり、コードが複雑になります。
再構築の無駄: setState()を呼び出すと、そのウィジェット全体が再構築されます。これにより、変更に関係のない部分も再描画され、パフォーマンスが低下することがあります。
ビジネスロジックとUIの混在: 複雑なビジネスロジックをウィジェット内に書くと、コードの可読性と保守性が低下します。

これらの限界を克服するために、グローバル状態管理の手法が開発されました。グローバル状態管理では、アプリ全体で状態を共有し、UIとロジックを分離します。これにより、コードの保守性が向上し、効率的な状態更新が可能になります。

Flutterにおける主要な状態管理手法の概要

Flutterエコシステムには多様な状態管理ソリューションが存在します。2025年現在、主に使用されている手法は以下の通りです：

Provider: Flutter公式が推奨する状態管理ライブラリです。依存性注入のパターンに基づき、シンプルなAPIで状態を管理します。小〜中規模のアプリに適しています。

// Providerの基本的な使用例
final counterProvider = Provider<int>((ref) => 0);

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ProviderScope(
      child: MaterialApp(
        home: CounterScreen(),
      ),
    );
  }
}

Riverpod: Providerの進化版で、より型安全性が高く、テスト容易性に優れています。Providerの問題点を解決し、より柔軟な状態管理を実現します。
BLoC (Business Logic Component): ストリームベースの状態管理手法で、イベントと状態のストリームを使用してデータの流れを管理します。大規模アプリや複雑なデータフローに適しています。
Redux: 予測可能な状態管理のためのライブラリで、単一の状態ツリーとアクション・リデューサーを使用します。厳格な構造を持ち、デバッグが容易です。
MobX: 反応型プログラミングアプローチに基づき、状態変更を自動的に検出し、UIを更新します。
GetX: 状態管理、ルーティング、依存性注入を統合したオールインワンのソリューションです。シンプルなAPIで高速な開発が可能です。

これらの手法はそれぞれ異なる哲学とアプローチを持っており、アプリの複雑さやチームの好みに応じて選択するのが良いでしょう。以降のセクションでは、特に広く使われている「Provider」「Riverpod」「BLoC」の3つの手法について詳しく解説し、それぞれの使い分け方を見ていきます。

Providerを使った状態管理：シンプルで効率的なアプローチ

Provider基礎：セットアップと基本的な使い方

Providerは、Flutterチームが公式に推奨する状態管理ライブラリで、依存性注入（DI）パターンに基づいています。簡単なセットアップで使い始められ、学習曲線が緩やかなのが特徴です。

まずは基本的なセットアップから見ていきましょう：

依存関係の追加：pubspec.yamlファイルに以下を追加します：

dependencies:
  flutter:
    sdk: flutter
  provider: ^6.1.1  # 2025年5月現在の最新バージョン

基本的な使い方：Providerには様々な種類がありますが、最も基本的なProviderクラスは以下のように使います：

// データモデル
class Counter {
  int value = 0;
}

// アプリのルートでProviderを設定
void main() {
  runApp(
    Provider<Counter>(
      create: (context) => Counter(),
      child: MyApp(),
    ),
  );
}

// 子ウィジェットでProviderからデータを取得
class CounterText extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // Providerからデータを読み取り
    final counter = Provider.of<Counter>(context);
    return Text('${counter.value}');
  }
}

複数のProviderを使用する場合：MultiProviderを使って複数のProviderをまとめて管理できます：

void main() {
  runApp(
    MultiProvider(
      providers: [
        Provider<Counter>(create: (context) => Counter()),
        Provider<UserRepository>(create: (context) => UserRepository()),
        // 他のプロバイダー...
      ],
      child: MyApp(),
    ),
  );
}

データの取得方法：Providerからデータを取得するには以下の3つの方法があります：

Provider.of<T>(context)：ビルドメソッド内で使用すると、値の変更時にウィジェットが再構築されます
context.watch<T>()：Provider.ofと同様に、値の変更を監視します
context.read<T>()：現在の値を一度だけ読み取り、変更を監視しません（イベントハンドラ内での使用に適しています）

// 3つの異なる取得方法
Widget build(BuildContext context) {
  // 方法1: Provider.of
  final counter1 = Provider.of<Counter>(context);
  
  // 方法2: context.watch() - 変更を監視
  final counter2 = context.watch<Counter>();
  
  // 方法3: context.read() - 一度だけ読み取り
  return ElevatedButton(
    onPressed: () {
      final counter3 = context.read<Counter>();
      print(counter3.value);
    },
    child: Text('値: ${counter1.value}'),
  );
}

これらの基本的な使い方を理解すれば、Providerを使った状態管理の基礎が身につきます。次にさらに実用的な例として、ChangeNotifierProviderを見ていきましょう。

ChangeNotifierProviderを使った実装例

ChangeNotifierProviderは最も頻繁に使用されるProvider型の一つで、変更可能な状態を管理するのに最適です。ChangeNotifierクラスを拡張したモデルクラスと組み合わせて使用します。

以下は、買い物かごアプリを例にした実装です：

// ChangeNotifierを拡張したモデルクラス
class CartModel extends ChangeNotifier {
  // 買い物かごのアイテムリスト
  final List<Item> _items = [];
  
  // ゲッター
  List<Item> get items => _items;
  int get totalPrice => _items.fold(0, (sum, item) => sum + item.price);
  
  // アイテム追加メソッド
  void addItem(Item item) {
    _items.add(item);
    // 状態が変更されたことを通知
    notifyListeners();
  }
  
  // アイテム削除メソッド
  void removeItem(Item item) {
    _items.remove(item);
    notifyListeners();
  }
  
  // カートをクリア
  void clearCart() {
    _items.clear();
    notifyListeners();
  }
}

// アイテムモデル
class Item {
  final String id;
  final String name;
  final int price;
  
  Item({required this.id, required this.name, required this.price});
}

次に、このモデルをアプリで使用する方法を見てみましょう：

void main() {
  runApp(
    // CartModelのインスタンスを提供
    ChangeNotifierProvider(
      create: (context) => CartModel(),
      child: MyApp(),
    ),
  );
}

// カート一覧画面
class CartScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // CartModelを監視
    final cart = context.watch<CartModel>();
    
    return Scaffold(
      appBar: AppBar(
        title: Text('ショッピングカート'),
        actions: [
          IconButton(
            icon: Icon(Icons.delete),
            onPressed: () => cart.clearCart(),
          ),
        ],
      ),
      body: ListView.builder(
        itemCount: cart.items.length,
        itemBuilder: (context, index) {
          final item = cart.items[index];
          return ListTile(
            title: Text(item.name),
            subtitle: Text('¥${item.price}'),
            trailing: IconButton(
              icon: Icon(Icons.remove_circle),
              onPressed: () => cart.removeItem(item),
            ),
          );
        },
      ),
      bottomNavigationBar: BottomAppBar(
        child: Padding(
          padding: EdgeInsets.all(16.0),
          child: Text(
            '合計: ¥${cart.totalPrice}',
            style: TextStyle(fontSize: 20, fontWeight: FontWeight.bold),
          ),
        ),
      ),
    );
  }
}

// 商品一覧画面
class ProductScreen extends StatelessWidget {
  final List<Item> products = [
    Item(id: '1', name: 'Tシャツ', price: 2500),
    Item(id: '2', name: 'ジーンズ', price: 5000),
    Item(id: '3', name: 'スニーカー', price: 8000),
  ];
  
  @override
  Widget build(BuildContext context) {
    // コンテキストを使ってCartModelにアクセス
    return Scaffold(
      appBar: AppBar(title: Text('商品一覧')),
      body: ListView.builder(
        itemCount: products.length,
        itemBuilder: (context, index) {
          final product = products[index];
          return ListTile(
            title: Text(product.name),
            subtitle: Text('¥${product.price}'),
            trailing: IconButton(
              icon: Icon(Icons.add_shopping_cart),
              onPressed: () {
                // context.read()で一度だけ読み取り
                context.read<CartModel>().addItem(product);
                ScaffoldMessenger.of(context).showSnackBar(
                  SnackBar(content: Text('${product.name}をカートに追加しました')),
                );
              },
            ),
          );
        },
      ),
    );
  }
}

このように、ChangeNotifierProviderを使うことで、状態の変更を監視し、UIを自動的に更新することができます。notifyListeners()メソッドを呼び出すと、そのプロバイダーを監視しているウィジェットが再ビルドされます。

Providerのメリットと適した使用シーン

Providerが持つ主なメリットと、どのようなプロジェクトに適しているかを見ていきましょう。

メリット：

シンプルさ：APIがシンプルで理解しやすく、学習コストが低いです。
公式サポート：Flutter Teamによって公式に推奨されているため、ドキュメントが充実しており、将来的な安定性も期待できます。
柔軟性：様々な種類のProvider（Provider, ChangeNotifierProvider, FutureProvider, StreamProviderなど）があり、異なるユースケースに対応できます。
テスト容易性：依存性注入パターンに基づいているため、モックオブジェクトを使用したテストが容易です。
パフォーマンス：必要な部分だけを再ビルドできるため、効率的なUI更新が可能です。

適した使用シーン：

小〜中規模のアプリケーション：複雑すぎない状態管理が必要なアプリに最適です。
チーム開発の初期段階：学習コストが低いため、チームメンバーが素早く理解できます。
プロトタイプや迅速な開発：セットアップが簡単で、すぐに実装を始められます。
UI主導の状態管理：特にUI状態の管理が中心のアプリケーションに適しています。
Flutterの標準に沿った開発：公式推奨ライブラリを使いたい場合に最適です。

使用を避けるべきケース：

複雑な状態依存関係：状態間の複雑な依存関係がある場合、Riverpodの方が適しているかもしれません。
大規模なエンタープライズアプリケーション：非常に複雑なデータフローを持つ大規模アプリでは、BLoCなどのより構造化されたアプローチが適しているかもしれません。

「プログラムは単純であるべき、単純でなければならない」というアプリケーション開発の基本原則に忠実なProviderは、多くのシナリオで最初の選択肢として検討すべきライブラリです。必要に応じて、より高度な状態管理手法に移行することも可能です。

実践的なFlutter状態管理ベストプラクティス

テスト容易性を考慮した状態管理設計

テスト容易性は良い状態管理設計の重要な要素です。以下のベストプラクティスを検討してください：

1. 依存性の注入: テスト時に依存関係をモックに置き換えられるようにします。

// 悪い例: 直接インスタンス化
class UserRepository {
  final api = Api();  // テスト時に置き換えられない
  
  Future<User> getUser(String id) async {
    return await api.fetchUser(id);
  }
}

// 良い例: コンストラクタで注入
class UserRepository {
  final Api api;
  
  UserRepository(this.api);  // 依存性を注入
  
  Future<User> getUser(String id) async {
    return await api.fetchUser(id);
  }
}

// テストコード
test('getUser returns correct user', () async {
  final mockApi = MockApi();
  when(mockApi.fetchUser('123')).thenAnswer((_) async => User(id: '123', name: 'Test'));
  
  final repository = UserRepository(mockApi);
  final user = await repository.getUser('123');
  
  expect(user.id, '123');
  expect(user.name, 'Test');
});

2. ビジネスロジックとUIの分離: ビジネスロジックをウィジェットから分離し、単体テスト可能にします。

// 悪い例: ウィジェット内にロジックが混在
class LoginScreenState extends State<LoginScreen> {
  String _username = '';
  String _password = '';
  
  Future<void> _login() async {
    // バリデーションロジック
    if (_username.isEmpty || _password.isEmpty) {
      showError('ユーザー名とパスワードを入力してください');
      return;
    }
    
    // API呼び出し
    try {
      final response = await http.post(
        Uri.parse('https://api.example.com/login'),
        body: {'username': _username, 'password': _password},
      );
      // レスポンス処理...
    } catch (e) {
      // エラー処理...
    }
  }
  
  @override
  Widget build(BuildContext context) {
    // UIコード...
  }
}

// 良い例: ロジックを分離
class AuthService {
  final HttpClient client;
  
  AuthService(this.client);
  
  Future<Result<User>> login(String username, String password) async {
    // バリデーション
    if (username.isEmpty || password.isEmpty) {
      return Result.error('ユーザー名とパスワードを入力してください');
    }
    
    try {
      final response = await client.post(
        Uri.parse('https://api.example.com/login'),
        body: {'username': username, 'password': password},
      );
      // レスポンス処理...
      return Result.success(user);
    } catch (e) {
      return Result.error(e.toString());
    }
  }
}

// UI側
class LoginScreen extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    // UIコード...
    ElevatedButton(
      onPressed: () async {
        final result = await ref.read(authServiceProvider).login(username, password);
        result.when(
          success: (user) => navigateToHome(user),
          error: (message) => showError(message),
        );
      },
      child: Text('ログイン'),
    );
  }
}

3. テスト用の状態管理ヘルパー: テストを容易にするヘルパー関数やクラスを作成します。

// Riverpodテスト用ヘルパー
ProviderContainer createTestContainer({
  List<Override> overrides = const [],
}) {
  return ProviderContainer(
    overrides: overrides,
  );
}

// テストコード
test('counterProvider increments correctly', () {
  final container = createTestContainer(
    overrides: [
      // 依存するプロバイダーをオーバーライド
      loggerProvider.overrideWithValue(MockLogger()),
    ],
  );
  
  expect(container.read(counterProvider), 0);
  
  container.read(counterProvider.notifier).increment();
  
  expect(container.read(counterProvider), 1);
});

4. 状態のイミュータビリティ: 不変の状態クラスを使用して、予測可能性を向上させます。

// イミュータブルな状態
@immutable
class UserState {
  final String id;
  final String name;
  final List<Order> orders;
  
  const UserState({
    required this.id,
    required this.name,
    required this.orders,
  });
  
  // コピーコンストラクタ
  UserState copyWith({
    String? id,
    String? name,
    List<Order>? orders,
  }) {
    return UserState(
      id: id ?? this.id,
      name: name ?? this.name,
      orders: orders ?? this.orders,
    );
  }
}

これらの原則を適用することで、テスト可能で保守性の高い状態管理を実現できます。「テストしやすいコードは、良いコードである」という金言は、特に状態管理において真実です。

パフォーマンス最適化のための考慮点

Flutterアプリのパフォーマンスは、状態管理の方法に大きく影響されます。以下のポイントに注意して、パフォーマンスを最適化しましょう。

1. 適切な粒度の再構築: 必要なウィジェットだけを再構築するようにします。

// 悪い例: 全体が再構築される
class ProfileScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final user = context.watch<UserModel>();  // 変更があるたびに全体が再構築
    
    return Column(
      children: [
        UserHeader(user: user),
        UserStats(user: user),
        ExpensiveWidget(),  // 変更と無関係でも再構築される
      ],
    );
  }
}

// 良い例: 必要な部分だけ再構築
class ProfileScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        UserHeaderConsumer(),  // Consumer内部に状態監視を閉じ込める
        UserStatsConsumer(),
        ExpensiveWidget(),  // 再構築されない
      ],
    );
  }
}

class UserHeaderConsumer extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // ユーザー名のみを監視
    final userName = context.select((UserModel user) => user.name);
    return UserHeader(name: userName);
  }
}

2. 状態更新の遅延と一括処理: 短時間に複数の状態更新が発生する場合、それらをバッチ処理します。

// 悪い例: 複数の更新が個別に発生
void loadUserData() {
  setState(() { isLoading = true; });
  repository.getUser().then((user) {
    setState(() { this.user = user; });
    setState(() { isLoading = false; });
  });
}

// 良い例: 更新をバッチ処理
void loadUserData() {
  setState(() { isLoading = true; });
  repository.getUser().then((user) {
    setState(() {
      this.user = user;
      isLoading = false;  // 一度のsetStateで複数のフィールドを更新
    });
  });
}

3. メモ化: 計算コストの高い操作をメモ化します。

// Riverpodでのメモ化
final filteredTodosProvider = Provider<List<Todo>>((ref) {
  final todos = ref.watch(todosProvider);
  final filter = ref.watch(filterProvider);
  
  // フィルタが変わらなければ再計算しない
  return todos.where((todo) {
    switch (filter) {
      case Filter.all:
        return true;
      case Filter.completed:
        return todo.completed;
      case Filter.active:
        return !todo.completed;
    }
  }).toList();
});

4. 非同期処理の適切な管理: 非同期処理の結果を適切に管理します。

// FutureProviderを使用した非同期データ管理
final userProvider = FutureProvider.autoDispose.family<User, String>((ref, id) async {
  // 自動的にキャッシュされ、不要になると破棄される
  return await ref.watch(userRepositoryProvider).getUser(id);
});

// UI側
Consumer(
  builder: (context, ref, child) {
    final userAsync = ref.watch(userProvider(userId));
    
    return userAsync.when(
      data: (user) => UserProfile(user: user),
      loading: () => LoadingIndicator(),
      error: (error, stack) => ErrorWidget(error: error),
    );
  },
)

5. ディープリンクとウィジェットツリーの最適化: 複雑なネストを避け、必要に応じてウィジェットツリーを最適化します。

「プレマチュア最適化は諸悪の根源である」というのは有名な言葉ですが、状態管理に関しては初期段階から適切な設計を心がけることで、後の大規模なリファクタリングを避けることができます。

保守性の高い状態管理コードの書き方

長期的に保守性の高い状態管理コードを書くためのベストプラクティスを紹介します。

1. 明確なフォルダ構造: 状態管理コードを整理するための一貫したフォルダ構造を採用します。

lib/
├── features/           # 機能ごとのフォルダ
│   ├── auth/
│   │   ├── data/       # データソース
│   │   ├── domain/     # モデルとリポジトリインターフェース
│   │   ├── application/ # 状態管理（providers, blocs）
│   │   └── presentation/ # UI
│   ├── home/
│   └── settings/
├── core/               # 共通コード
│   ├── providers/      # グローバルプロバイダー
│   ├── models/         # 共通モデル
│   ├── utils/          # ユーティリティ
│   └── widgets/        # 共通ウィジェット
└── main.dart

2. 命名規則の一貫性: 明確で一貫した命名規則を採用します。

// Riverpodでの命名規則
// 読み取り専用のデータ
final userProvider = Provider<User>((ref) => User());

// 変更可能な状態
final counterProvider = StateNotifierProvider<CounterNotifier, int>((ref) => CounterNotifier());

// 非同期データ
final userDataProvider = FutureProvider<UserData>((ref) async => await fetchUserData());

// BLoCでの命名規則
// イベント
abstract class AuthEvent {}
class LoginRequested extends AuthEvent {}

// 状態
abstract class AuthState {}
class AuthInitial extends AuthState {}

3. コメントとドキュメンテーション: 複雑なロジックには適切なコメントを付けます。

/// ユーザー認証を管理するプロバイダー
/// 
/// アプリ全体で認証状態を共有し、ログイン・ログアウト処理を提供します。
/// ユーザーデータをセキュアに保存し、セッション管理を行います。
/// 
/// 使用例:
/// ```dart
/// final authState = ref.watch(authProvider);
/// if (authState is AuthStateLoggedIn) {
///   // ログイン済みの処理
/// }
/// ```
final authProvider = StateNotifierProvider<AuthNotifier, AuthState>((ref) {
  return AuthNotifier(ref.watch(authRepositoryProvider));
});

4. 単一責任の原則: 各クラスと関数に明確な責任を持たせます。

// 悪い例: 複数の責任を持つクラス
class UserManager {
  Future<User> fetchUser(String id) async { /* ... */ }
  Future<void> updateUserPreferences(Preferences prefs) async { /* ... */ }
  void navigateToProfile(BuildContext context) { /* ... */ }
  String formatUserName(User user) { /* ... */ }
}

// 良い例: 責任を分離
class UserRepository {
  Future<User> fetchUser(String id) async { /* ... */ }
  Future<void> updateUserPreferences(Preferences prefs) async { /* ... */ }
}

class UserFormatter {
  String formatUserName(User user) { /* ... */ }
}

class ProfileNavigator {
  void navigateToProfile(BuildContext context) { /* ... */ }
}

5. 一貫したエラー処理: エラー処理の戦略を統一します。

// 結果型を使用した一貫したエラー処理
class Result<T> {
  final T? data;
  final String? error;
  
  Result.success(this.data) : error = null;
  Result.error(this.error) : data = null;
  
  bool get isSuccess => error == null;
  
  void when({
    required Function(T) success,
    required Function(String) error,
  }) {
    if (isSuccess) {
      success(data!);
    } else {
      error(error!);
    }
  }
}

// 使用例
Future<Result<User>> getUser(String id) async {
  try {
    final user = await api.fetchUser(id);
    return Result.success(user);
  } catch (e) {
    return Result.error(e.toString());
  }
}

6. 段階的な抽象化: 必要に応じて抽象化レベルを増やし、柔軟性を向上させます。

// 基本的な抽象化層
abstract class AuthRepository {
  Future<User?> getCurrentUser();
  Future<Result<User>> login(String email, String password);
  Future<void> logout();
}

// 実装クラス
class FirebaseAuthRepository implements AuthRepository {
  @override
  Future<User?> getCurrentUser() async { /* ... */ }
  
  @override
  Future<Result<User>> login(String email, String password) async { /* ... */ }
  
  @override
  Future<void> logout() async { /* ... */ }
}

「最初からすべてを正しく設計することはできない」という認識のもと、コードは常に進化するものとして設計することが重要です。保守性の高いコードは、将来の変更に対応しやすく、チーム全体の生産性を向上させます。

まとめ：状態管理手法の使い分けとベストプラクティス

Flutter開発において状態管理は非常に重要な要素であり、適切な手法を選択することでアプリのパフォーマンス、保守性、テスト容易性が大きく向上します。ここでは、本記事で解説した内容を要約し、状態管理手法の使い分けのためのガイドラインを提供します。

各状態管理手法の特徴と使い分け:

Provider: シンプルで習得しやすく、公式に推奨されているため、多くのプロジェクトの最初の選択肢として適しています。小〜中規模のアプリや、シンプルな状態管理が必要な場合に最適です。
Riverpod: Providerの進化版で、より型安全性が高く、テスト容易性に優れています。中〜大規模のプロジェクトや、複雑な依存関係がある場合に適しています。コンパイル時のエラーチェックと柔軟な状態管理が魅力です。
BLoC: ストリームベースの状態管理で、大規模アプリや複雑なデータフローに適しています。明確なアーキテクチャと関心の分離により、チーム開発や長期的なメンテナンスが容易になります。

状態管理の選択基準:

プロジェクトの規模と複雑性: 小規模なプロジェクトではシンプルな手法（Provider）、大規模プロジェクトではより構造化された手法（BLoC/Riverpod）を選びます。
チームの経験とスキルセット: チームが既に慣れている手法を優先するか、学習コストの低い手法から始めることを検討しましょう。
プロジェクトの要件: リアルタイムデータを扱う場合はストリームベースの手法、複雑な依存関係がある場合はRiverpodなど、要件に合った手法を選びます。

状態管理のベストプラクティス: