Dartコレクションの要塞化：Unmodifiableビューのランタイム特性と防御的コピーの極意
Dartは、安全で予測可能なアプリケーションを構築するためのモダン言語として設計されている。しかし、「オブジェクトの参照渡し」という言語仕様の根幹を理解していない場合、どれほど厳格なNull安全や型システムを導入しても、カプセル化はいとも簡単に破られる。
特に、`List`や`Map`といったコレクションをクラスの外部へ公開する際、内部状態のリークや意図しない副作用（Side Effect）を防ぐためのアプローチは、シニアエンジニアであっても設計を誤ることが多い。
本稿では、Dart VMのメモリモデルとオブジェクトグラフの観点から、`UnmodifiableView`と「防御的コピー（Defensive Copy）」の本質的な違い、そしてコンパイル後の挙動とパフォーマンスのトレードオフを徹底的に解剖する。
—
1. カプセル化の崩壊：なぜ「参照」は危険なのか
まずは、誰もが犯しがちな初歩的なミス、そしてそこから生じるランタイムの脆弱性を見てみよう。
class SystemConfig {
// 内部の機密データ（あるいは変更されては困る状態）
final List
// 危険なgetter: 内部の参照をそのまま返している
List
}
void main() {
final config = SystemConfig();
// 外部から内部状態を直接書き換えられてしまう
config.allowedIps.add(‘666.666.666.666’);
print(config.allowedIps); // [192.168.1.1, 10.0.0.1, 666.666.666.666]
}
このコードの問題点は、`final`キーワードが「変数 `_allowedIps` が指すポインタ（参照）」の再代入を禁止しているだけであって、「参照先のリストオブジェクトそのもののミュータビリティ（可変性）」を何ら制限していない点にある。
Dart VMのヒープメモリにおいて、`_allowedIps` は特定の `GrowableList` インスタンスを指し示している。getter経由でその参照が流出した瞬間、カプセル化の防壁は崩壊する。
—
2. 防御的コピー（Defensive Copy）のコストと限界
この問題を解決する最も素朴なアプローチが「防御的コピー」である。データを返す際に、新しいコレクションインスタンスをヒープ上に複製して渡す手法だ。
class SystemConfigSecure {
final List
// 防御的コピーによるカプセル化
List
}
コンパイラとメモリの挙動
`List.from()` を呼び出した瞬間、Dart VMはヒープ上に全く新しい `GrowableList` をアロケートし、既存の要素への参照を新しい配列領域にコピー（シャローコピー）する。
- メリット: 完全に独立したメモリ領域を渡すため、呼び出し元が何をしようが内部の `_allowedIps` は絶対に汚染されない。
- デメリット（致命的）: $O(N)$ の時間計算量と、新たなメモリ割り当て（GCプレッシャーの増大）が発生する。このgetterがホットパス（高頻度で呼ばれるループ内など）で実行された場合、垃圾回収（Garbage Collection）の頻度が跳ね上がり、フレームドロップ（jank）の直接的な原因となる。
—
3. Unmodifiableビュー：ゼロコスト（に近い）抽象防壁
Dartの `dart:collection` ライブラリは、このパフォーマンスと安全性のジレンマに対する洗練された解を用意している。それが `UnmodifiableListView`（および `UnmodifiableMapView`）である。
import ‘dart:collection’;
class SystemConfigOptimized {
final List
late final List
// ビューを返す
List
}
内部実装とランタイムの仕組み
`UnmodifiableListView` は、元のリストへの参照を内部で保持しつつ、`List` インターフェースの「書き込み系メソッド」（`add`, `[]=`, `remove` など）をオーバーライドして、例外（`UnsupportedError`）を投げるように設計された軽量なラッパーである。
// 呼び出し元で書き込みを試みた場合
void main() {
final config = SystemConfigOptimized();
// 実行時エラー: UnsupportedError (Cannot modify an unmodifiable list)
config.allowedIps.add(‘10.0.0.2’);
}
アーキテクチャ上の優位性
1. メモリ割り当ての抑制: 新しいリストや配列のバッファを生成しない。生成されるのはわずか数ワードのラッパーオブジェクトのみである。
2. $O(1)$ の初期化コスト: コピーを行わないため、要素数に関わらず瞬間的にビューを構築できる。
3. 同期の維持: 内部の `_allowedIps` が変更された場合、その変更がビュー側からも（読み取り専用として）即座に反映される（※これが望ましくない場合は防御的コピーを選ぶべきである）。
—
4. `const` コレクションとの使い分け
Dart 2以降、`const` リストやマップを直接定義できるようになった。これも強力なイミュータビリティの担保手段である。
class SystemConfigConst {
// コンパイル時定数としてヒープの読み取り専用領域に配置される
static const List
}
決定的な違い：`const` vs `UnmodifiableView`
- `const` リスト:
- コンパイル時に評価され、定数プール（Constants Pool）に焼き込まれる。アプリケーションのライフサイクルを通じて一度しかアロケートされない（極限のメモリ効率）。
- ただし、クラスのインスタンス変数として、動的に変化する可能性のあるデータを保持する場合には使用できない。
- `UnmodifiableView`:
- 実行時に動的に生成されるミュータブルなデータ構造を、安全に読み取り専用として外部公開するためのパターンのためにある。
—
5. 【極限知見】深い（Deep）イミュータビリティの罠
シニアエンジニアであっても見落としがちなのが、「コレクションのビューをunmodifiableにしても、要素自体がミュータブルであれば、内部状態は破壊される」という事実だ。
class User {
String name;
User(this.name);
}
class Department {
final List
// リスト自体はUnmodifiableListViewで保護しているつもり
List
}
void main() {
final dept = Department();
//dept.users.add(User(‘Bob’)); // これはUnsupportedErrorで防げる
// しかし！ 要素が指し示す先（Userオブジェクトの内部状態）は変更可能
dept.users[0].name = ‘Eve’;
print(dept._users[0].name); // “Eve” に書き換わっている！
}
対策：真の安全性を求める場合
オブジェクトグラフの深部に至るまで完全なイミュータビリティを担保する必要がある場合（セキュリティ上の機密データやマルチスレッド分離等）、ビューの適用だけでは不十分である。
1. 要素自体を `immutable` にする（`@immutable` アノテーションと全てのフィールドの `final` 化）。
2. やむを得ずミュータブルなオブジェクトを内包する場合は、ビューではなく防御的コピー（ディープコピー）を選択するトレードオフを受け入れる。
—
まとめ：アーキテクチャ設計の指針
Dartにおけるコレクションの公開戦略は、以下のマトリクスに基づいて厳密に選択されなければならない。
| 要件 | 推奨アプローチ | 計算量 / メモリコスト |
| :— | :— | :— |
| 完全なコンパイル時定数 | `const […]` | $O(1)$ / ゼロ（定数プール） |
| 動的データの読み取り専用公開（高速・安全） | `UnmodifiableListView` / `UnmodifiableMapView` | $O(1)$ / 最小限のラッパーのみ |
| 完全な独立性の担保（呼び出し元からの汚染を断固拒絶） | 防御的コピー (`List.from()` / `.map().toList()`) | $O(N)$ / 新規アロケーション発生 |
言語のランタイム特性、ガベージコレクションの挙動、そしてオブジェクトグラフの参照関係を完全に支配した上でコードを書くこと。それこそが、真のDartマイスターに求められる素養である。