【テクニカル・上級編】Dart 3.0の「base」「interface」「final」修飾子によるクラス階層の制御 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dart 3.0 クラス修飾子の深淵：コンパイラとVtablesから見たAPI境界の完全制御

Dart 3.0における `base`, `interface`, `final` といったクラス修飾子の導入は、単なる言語仕様の拡張ではない。これは、オブジェクト指向言語の設計者が長年抱えてきた「カプセル化の崩壊」という構造的脆弱性に対する、コンパイラレベルの厳格な防壁である。

我々ランタイムエンジニアにとって、クラス階層とは単なる概念モデルではなく、メモリレイアウト、仮想メソッドテーブル（Vtable）のディスパッチ、そしてAOT（Ahead-Of-Time）コンパイル時のデバッギング戦略に直接影響を与える物理的な制約である。

本稿では、Dart 3.0のクラス修飾子がコンパイル時にどのように解釈され、実行時（Dart VM）のメモリ最適化やセキュリティ境界にどう寄与するのか、その低レイヤの真実を暴く。

—

1. なぜ「デフォルトの開放性」はアーキテクチャを破壊するのか

Dart 2までの世界では、すべてのクラスは暗黙的に `interface` であり、かつ `extends` も `implements` も可能であった。これはオープンワールド・プログラミングにおいては柔軟性をもたらすが、大規模なフレームワークやセキュリティクリティカルなライブラリを書く者にとっては悪夢でしかない。

ライブラリの作者が意図しないサブクラス化や実装（implements）が行われると、以下の問題が発生する。

1. Vtable（仮想メソッドテーブル）の静的最適化の阻害: コンパイラがメソッド呼び出しをインライン展開（Inlining）したり、単態ディスパッチ（Monomorphic Dispatch）に最適化できなくなる。
2. 内部状態（State）の漏洩と破壊: 基底クラスが想定していないフィールドがサブクラスによって追加され、メモリ上のオフセット計算が狂う、あるいはカプセル化が破られる。

Dart 3.0はこの暗黙の自由を剥奪し、開発者が「APIの意図」をコンパイラにハードコードすることを可能にした。

—

2. 三つの防壁：`base`, `interface`, `final` のコンパイル時セマンティクス

それぞれの修飾子が、同一ライブラリ内（Same Library）と外部ライブラリ（External Library）でどのような制約を持つのか、コンパイラの視点で整理する。

| 修飾子 | 同一ライブラリ内での継承 (`extends`) | 同一ライブラリ内での実装 (`implements`) | 外部ライブラリでの継承 (`extends`) | 外部ライブラリでの実装 (`implements`) |
| :— | :— | :— | :— | :— |
| `base` | 可 | 不可 | 可 | 不可 |
| `interface` | 可 | 可 | 不可 | 不可 |
| `final` | 不可 | 不可 | 不可 | 不可 |

このマトリクスが意味するのは、「外部からの実装を強制的に禁止し、型の安全性を担保する」という強固な防御壁の構築である。

`base`: 実装の継承を強制し、多重実装の混乱を防ぐ

`base` 修飾子は、クラスの「実装」が継承されることは許すが、インターフェースとしての型だけを勝手に流用（`implements`）することを禁じる。

// library_a.dart
base class SecureBuffer {
final List_internalData = [];

// 内部状態を変更するクリティカルなメソッド
void write(int data) {
_internalData.add(data);
}
}

もし外部ライブラリで `implements SecureBuffer` が許可されてしまうと、`_internalData` という物理的なフィールドの存在を無視した偽の実装が生まれ、ランタイムで予期せぬメモリレイアウトの矛盾を引き起こす。`base` はこれをコンパイルエラーとして弾く。

`interface`: 振る舞いの契約のみを公開し、内部実装の結合を断つ

逆に、内部実装を一切共有させず、インターフェースの契約（署名）だけを強制したい場合は `interface` を使う。

// library_b.dart
interface class PluginContract {
void initialize();
void dispose();
}

外部ライブラリはこのクラスを `implements` することはできるが、`extends` して既存のロジックを流用することはできない。これにより、基底クラス側のコード変更が外部のサブクラスに影響を与える「脆弱な基底クラス問題（Fragile Base Class Problem）」を根絶できる。

`final`: 継承ツリーの完全な終端

`final` は、そのクラス階層の歴史をそこで完結させる。同一ライブラリ内であっても拡張を許さない。

// library_c.dart
final class ImmutableConfig {
final String endpoint;
const ImmutableConfig(this.endpoint);
}

—

3. ランタイム最適化への影響：AOTコンパイラとVtableの静的解決

Dart VMおよびAOTコンパイラ（`gen_snapshot`）にとって、クラスが `final` や `base`（かつ外部からのサブクラス化がない状態）であるという情報は、コード生成において極めて強力な最適化のヒント（Optimization Hint）となる。

クラス階層解析（Class Hierarchy Analysis: CHA）の精度向上

クラスが `final` または `interface`（外部から `extends` されない）であると確定した場合、コンパイラはCHAを実行する際、そのクラスのサブタイプが存在しない、あるいは限定的であると断定できる。

これにより、以下の最適化がアグレッシブに行われる。

1. Devirtualization（仮想メソッドの静的ディスパッチ化）:
通常、オブジェクト指向言語のメソッド呼び出しは、実行時にVtableを参照してどのメソッドを実行すべきか解決する（Dynamic Dispatch）。しかし、対象のクラスが拡張不可能であれば、コンパイル時に呼び出し先を静的に特定でき、ダイレクトコール（Direct Call）に変換できる。これにより、CPUのパイプラインハザードや分岐予測ミスのコストを劇的に削減できる。

2. Tree Shakingの極限化:
Flutterアプリケーションのビルド時、使われていないコードを削ぎ落とすTree Shakingが行われる。クラス階層が閉じている（Closed World）ほど、コンパイラはどのメソッドが絶対に呼ばれないかを正確に追跡できるため、バイナリサイズを極限まで小さく抑えることが可能になる。

—

4. アーキテクチャの実践：安全なステート管理の設計

これらの修飾子を組み合わせ、外部から改ざん不可能なセキュアな非同期イベントパイプラインを構築する例を見てみ5よう。

// 秘匿すべきトランザクションを処理するコアエンジン
library transaction_engine;

import ‘dart:async’;

/// 1. 状態の基底。外部での継承を許可するが、実装のみ（base）
base class TransactionContext {
final String _transactionId;
bool _isCommitted = false;

TransactionContext(this._transactionId);

bool get isCommitted => _isCommitted;

// 内部でのみコミット状態を反転させる
void markCommitted() {
_isCommitted = true;
}
}

/// 2. 外部公開するパイプライン制御インターフェース
/// 外部ライブラリはこのコントラクトをimplementsすることしかできない。
interface class TransactionPipeline {
Future execute(TransactionContext context) async {
// デフォルトの防御的実装
throw UnimplementedError(‘Pipeline not initialized.’);
}
}

外部の利用者がこのアーキテクチャに介入する場合、彼らは勝手に `TransactionContext` の内部フィールド構造を書き換えるようなサブクラスを作ることができず、また `TransactionPipeline` の契約に則った実装を強制される。

もし外部パッケージで以下のようなコードを書こうものなら：

// 外部パッケージの悪意ある、あるいは無知なコード
import ‘package:transaction_engine/transaction_engine.dart’;

// コンパイルエラー: baseクラスは外部からimplementsできない
class MaliciousContext implements TransactionContext {
@override
String get _transactionId => ‘hack’;
// …
}

コンパイラは即座にエラーを吐き、システムの整合性を死守する。

—

5. チーフアーキテクトからの提言

Dart 3.0のクラス修飾子は、単なる「お作法」の強制ではない。それは、「コンパイラにコードの意図を正確に伝え、実行時のオーバーヘッドを極限まで削ぎ落とすためのハードウェアに近い制御言語」である。

大規模なFlutterアプリケーションや、セキュアなDartバックエンド（Serverpod等）を設計する際、全てのクラスを無思考に `class` と宣言することは、パフォーマンスとセキュリティの両面において怠慢と言わざるを得ない。

APIを設計する際は、常に自問すべきである：

「このクラスは拡張されるべきか？（ならば `base`）」
「このクラスはインターフェースとしてのみ振る舞うべきか？（ならば `interface`）」
「このクラスは完全に孤立した不変の存在であるべきか？（ならば `final`）」

この選択の積み重ねこそが、予測可能で、堅牢で、ネイティブに近い速度で駆動するDartシステムの基盤となるのだ。