【実務・中級編】DartのNull安全とFuture/Streamの非同期処理における型定義 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dartの型システムを飼い慣らせ：`Future` と `FutureOr` の深淵

DartのSound Null Safetyは、単なる「Nullポインタ例外を防ぐためのガード」ではない。コンパイラが型推論の段階で「実行時に値が存在するか否か」を静的に証明するための、強力な推論エンジンだ。

しかし、非同期処理において `Future` や `FutureOr` を雑に扱うと、この型システムの恩恵を自らドブに捨てることになる。本稿では、我々がプロダクション環境で「なぜその型を選ぶのか」を、VMの内部挙動まで見据えて解説する。

—

1. `Future` と `FutureOr` の決定的な境界線

多くの開発者がこの二つを混同しているが、設計意図は全く異なる。

`Future`：明示的な「値の不在」

これは「非同期処理の結果として、値が存在しない（null）可能性がある」ことを意味する。

用途: APIレスポンスが「データなし」を正常系として返す場合。
注意: 受取側は必ずNullチェック（または `if (res != null)`）を強制される。

`FutureOr`：同期と非同期の「ハイブリッド」

これは「処理の結果が即座に確定しているか（同期）、あるいはFutureとして返されるか（非同期）を型システムで抽象化する」ためのものだ。

用途: キャッシュ機構の実装。キャッシュヒットなら即座に `T` を返し、ミスなら `Future` を返す。
メリット: 無駄な `Future` インスタンスの生成を抑止し、VMのマイクロタスクキューを汚染しない。

—

2. 現場で「バグを埋め込まない」ための設計パターン

APIクライアントを例に、堅牢な設計を見てみよう。

import ‘dart:async’;

/// ユーザー情報を取得するリポジトリ
/// 戻り値に FutureOr を使うことで、パフォーマンスと型安全を両立する
abstract class UserRepository {
// キャッシュがあれば即座に返し、なければ非同期で取得する
FutureOr getUser(String id);
}

class UserApiRepository implements UserRepository {
final Map _cache = {};

@override
FutureOr getUser(String id) {
// キャッシュヒット時は Future のオーバーヘッドを発生させない
if (_cache.containsKey(id)) {
return _cache[id];
}

// 非同期通信時は Future を返す
return _fetchFromNetwork(id);
}

Future _fetchFromNetwork(String id) async {
// ネットワーク処理…
return null; // 存在しない場合
}
}

// 利用側のコード
Future displayUser(String id, UserRepository repo) async {
// ここで FutureOr の真価が発揮される
// await を使うことで、同期/非同期を意識せず安全に型解決できる
final user = await repo.getUser(id);

// Null Safety により、userがnullである可能性を強制的に考慮させる
if (user == null) {
print(‘User not found.’);
return;
}
print(‘User: ${user.name}’);
}

なぜこれが美しいのか？

1. 不必要な非同期化の回避: キャッシュヒット時に `Future.value()` を生成すると、コンパイラはそれをイベントループのタスクとしてスケジュールする。`FutureOr` を使えば、同期的な戻り値は即座に評価され、VMのオーバーヘッドを最小化できる。
2. 型推論の完全性: `await` は `FutureOr` を透過的に扱う。呼び出し側は「相手が同期か非同期か」を気にする必要がなく、ビジネスロジックに集中できる。

—

3. パフォーマンスの深層：コンパイラとVMの視点

DartのAOTコンパイラにとって、`Future` は「実行時に `null` か `T` かを判定するためのフラグ」を管理するコストを持つ。

もし、あなたが `Future` を使うべき場面で `Future` を使っているなら、それは「本来なら存在し得ないはずのデータ」を許容している設計上の欠陥である。

アンチパターン: `Future?>` のような多重Null許容型。
これが発生する場合、設計を見直すべきだ。空のリスト `[]` を返すのと、`null` を返すのでは、型安全性が天と地ほど違う。「データがない」という状態を `null` に押し付けない。「空」は「空」として型定義する。

—

4. チーフアーキテクトからの助言：Null安全を「守り」から「攻め」へ

実務において、Null安全を単なる「エラー回避ツール」として使っているうちは二流だ。「Nullを許容しない設計こそが、最もコストの低いドキュメントになる」ということを忘れてはならない。

1. APIの契約: `Future` を受け取ったら、その瞬間に「なぜ値がないのか？」を検討し、Nullチェックではなく、`null` が返る可能性を排除できるようなサーバー側の設計変更を提言せよ。
2. 型変換のコスト: `FutureOr` を使いこなすことは、Dart VMのイベントループにおける「不必要なタスク生成」を抑制することと同義だ。大規模なアプリケーションになるほど、この微細な差がレスポンスの体感速度に直結する。

結論

`Future` は「可能性としてのNull」を表現し、`FutureOr` は「実行効率と抽象化」を両立する。この二つを正しく使い分けるだけで、コードベースから「意味不明なランタイムエラー」を根絶できる。

我々の仕事は、コンパイラが最も気持ちよく最適化できるよう、型という名の厳格なルールを書き記すことだ。コードレビューでは、妥協して `!` や `?` を付ける前に、「なぜこの型定義が最適なのか」を自問自答してほしい。

それが、伝説的なアーキテクトへの第一歩だ。