【テクニカル・上級編】Dartの「base」「interface」「final」修飾子による、変数宣言時の継承・実装制限 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

APIの絶対防衛圏：Dart 3クラス修飾子（`base`, `interface`, `final`）の低レイヤ実像とコンパイル時最適化

Dart 3における `base`, `interface`, `final` クラス修飾子の導入は、単なる「オブジェクト指向の構文拡張」などではない。これは、ライブラリ境界を越えたバイナリの整合性を保証し、AOT（Ahead-Of-Time）コンパイラとDart VMのランタイム最適化を極限まで引き出すための構造的防壁である。

ネット上の浅い解説では「継承できるかどうか」「implementsできるかどうか」という表層的なルールに終始しがちだ。しかし、シニアエンジニアやランタイムの挙動に踏み込む者が理解すべきは、これらの修飾子がコンパイル時のVTable（仮想メソッドテーブル）構築、インラインキャッシュ（IC）、そしてオブジェクトのメモリレイアウトにどう影響するかという点に他ならない。

本稿では、Dartコアコミッターの視点から、これら修飾子がコンパイラとVMの挙動に与える影響を剥き出しにし、堅牢なAPI設計の極意を紐解く。

—

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

Dart 2時代、すべてのクラスはデフォルトで「どこからでも継承・実装が可能」であった。これはプロトタイピングには便利だが、大規模なエンタープライズシステムやプラグインエコシステムにおいては致命的な脆弱性を生む。

ライブラリの作者が `class Widget` を提供したとき、外部の人間がそれを勝手に `extends` または `implements` し、内部のプライベートなメソッド名を偶然オーバーライドしたり、スーパークラスのコンストラクタ規約を無視したインスタンスを生成したりするリスク（脆弱な基底クラス問題：Fragile Base Class Problem）が常に存在した。

これは、ランタイムにとっても悪夢である。
ポリモーフィズムが無限に許可されていると、コンパイラは動的なディスパッチ（VTable経由の呼び出し）を多用せざるを得ず、Devirtualization（脱仮想化） やインライン展開といった強力な最適化の機会が失われる。

この膠着状態を打破し、APIの安全領域とコンパイラの最適化領域を同時に死守するために導入されたのが、Dart 3のクラス修飾子である。

—

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

それぞれの修飾子が、コンパイラおよびアナライザーにどのような制約を課し、バイナリ生成時にどう作用するかを厳密に定義する。

修飾子比較マトリクス

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

> 知見: ライブラリ（Library）の単位はファイル単位ではなく、`library` 指示子またはパッケージ単位（`part` を含む）のスコープであることに注意せよ。同一パッケージ内であれば、これらの制限はバイパスされる。これはモジュール内部のカプセル化と外部公開APIを分離するための設計である。

—

3. コードで見る挙動とコンパイルエラーの裏側

実際にコードを通じて、コンパイラがどのように検知し、バイナリ生成を拒絶するのかを確認する。

// === ibrary: graphics_engine ===
library graphics_engine;

// 1. base class: 継承は許可するが、実装（implements）は絶対に許さない。
// 内部のロジックやフィールド構造（Memory Layout）の整合性を担保する。
base class RenderNode {
int _zOrder = 0; // 内部状態の保護

void render() {
// 描画の基底処理
}
}

// 2. interface class: 実装は許可するが、継承（extends）による状態の共有は許さない。
// 契約（Contract）のみを強制したい場合に用いる。
interface class Transformable {
void scale(double factor);
void rotate(double angle);
}

// 3. final class: 継承も実装も一切拒絶する。
// 終端クラスとして完全な振る舞いをカプセル化する。
final class PixelShader {
void apply() {
// シェーダーの最適化処理
}
}

外部ライブラリ（あるいは別ファイル）からの不正なアクセス

import ‘graphics_engine.dart’;

// コンパイルエラー: baseクラスを implements することはできない
// 理由: メモリ上のフィールドレイアウトの破壊を防ぐため
class CustomNode implements RenderNode {
@int _zOrder = 0; // Error!
void render() {}
}

// コンパイルエラー: interfaceクラスを extends することはできない
// 理由: スーパークラスのコードや内部状態の継承を意図していないため
class MatrixTransform extends Transformable {
// Error!
void scale(double factor) {}
void rotate(double angle) {}
}

// コンパイルエラー: finalクラスは拡張も実装もできない
class CustomShader extends PixelShader {
// Error!
}

—

4. 低レイヤ視点：なぜこれらの修飾子がVMのパフォーマンスを向上させるのか？

ここからが本稿の真骨頂である。Dart VMとAOTコンパイラ（`gen_snapshot`）は、これらの修飾子をどのように利用してパフォーマンスを極限まで高めているのか。

A. 脱仮想化（Devirtualization）とインライン化

通常、オブジェクト指向言語では、メソッド呼び出し `node.render()` が実行される際、どのクラスのメソッドが呼ばれるかは実行時まで分からないため、VTableを参照するオーバーヘッド（間接ジャンプ）が発生する。

しかし、クラスが `final`、あるいは継承されないことが静的に保証されている `base` クラス（かつサブクラスが存在しない、あるいはClosed World Assumptionが成り立つ場合）において、AOTコンパイラはダイナミックディスパッチを静的ディスパッチ（Direct Call）に変換する。さらにその関数本体を呼び出し元にインライン展開（Inlining）することで、関数呼び出しのオーバーヘッドを完全に消し去る。

B. オブジェクトのメモリレイアウトとフィールドアクセス最適化

`base` 修飾子は、インスタンス変数のメモリ上のオフセットを固定化する上で極めて重要である。もし外部から勝手に `implements` を許してしまうと、クラスが持つべきフィールドの順序やサイズ（Object Headerに続くPayloadの構造）の予測が困難になり、JIT/AOTコンパイラによるメモリアクセスの最適化（Load/Storeのベクトル化やキャッシュラインの効率化）が阻害される。

`base` によって継承ツリーが厳格に管理されることで、コンパイラはインスタンスのメモリオフセットをコンパイル時にハードコードでき、CPUのキャッシュヒット率を最大化できる。

—

5. 実戦的設計戦略：APIの安全性を構築するパターン

実務において、これらの修飾子をどう使い分けるべきか。シニアアーキテクトが実践する設計指針を提示する。

1. ドメインモデルやエンティティの基底には `base` を使う

共通の内部状態（IDやタイムスタンプなど）を持ちつつ、サブクラスでの振る舞いの拡張を許容したい場合。外部に「インターフェースとしてだけ使わせる」のではなく、正当な血統（Inheritance）を強制する。

2. 振る舞いの契約（Mixin-likeな抽象）には `interface` を使う

状態を持たず、特定のメソッド群の実装を強制したい場合。ミックスインや従来のJavaのインターフェースに近い使い方をし、誤った実装の継承を防ぐ。

3. ユーティリティや最終的な具象クラスには `final` を使う

これ以上拡張する必要がない、あるいは拡張されるとセキュリティや整合性が崩れるクラスは、最初から `final` で封印する。ライブラリ設計者の意図しないサブクラス化を防ぐ最強の防壁となる。

—

結言

Dart 3のクラス修飾子は、単なる「モダンな言語機能」の模倣ではない。それは、大規模なコードベースにおいて「コンパイラに語らせる制約」を増やし、人間がレビューしきれない領域の安全性をランタイムとコンパイラに肩代わりさせるための最高のアダプターである。

変数の宣言、クラスの定義、その一つひとつの修飾子に「なぜこの防壁が必要なのか」という意志を持たせよ。それこそが、プロダクトを破綻から守り抜く、真のエンジニアリングである。