Hackにおける構造的型付けと公称的型付けの深淵：Shapeか、Interfaceか
Hackの静的型システムは、単なる「バグ防止ツール」ではない。それはHHVMのJIT（Just-In-Time）コンパイラが機械語を生成するための、極めて厳密なヒントである。
中級からシニアへとステップアップする際、多くのエンジニアが「`shape`を使うべきか、`interface`でクラスを定義すべきか」という境界線で迷う。この問いに対する答えは、言語の表面的な利便性ではなく、「データがシステム内をどう伝播し、どのようなライフサイクルを持つか」というアーキテクチャの根幹に宿る。
本稿では、HHVMのランタイム挙動と型検査の制約から、この設計の境界線を解き明かす。
—
1. 構造的型付け（Shape）の「軽さ」と「危うさ」
`shape`は、構造的型付け（Structural Typing）の権化だ。HHVMにおいて、shapeは単なるアレイの特殊な形式であり、メモリ上では効率的に表現される。
type UserData = shape(
‘id’ => int,
‘username’ => string,
);
function processUser(UserData $user): void {
// $user[‘id’] へのアクセスは、連想配列のハッシュルックアップではなく、
// HHVM内部でオフセットアクセスとして最適化される。
}
なぜShapeを使うのか
- データの搬送能力: 外部APIのJSONレスポンスや、データベースのクエリ結果を型安全にマッピングする際、クラスを定義するのはオーバーヘッドだ。
- 軽量な構造: メソッドを持たない純粋なデータ運搬体（Data Transfer Object）であれば、Shapeはクラスインスタンスよりもメモリフットプリントが小さく、GCのプレッシャーも低い。
警鐘: Shapeは「データ」には最強だが、「振る舞い」を隠蔽することはできない。ロジックをshapeに紐付けようとした瞬間、君のコードはスパゲッティへと変貌する。
—
2. 公称的型付け（Interface/Class）の「重み」と「契約」
一方、`interface`は公称的型付け（Nominal Typing）に基づく。これは「名前」が型を決定する。
interface UserInterface {
public function getDisplayName(): string;
}
class RegisteredUser implements UserInterface {
public function __construct(private int $id, private string $name) {}
public function getDisplayName(): string { return $this->name; }
}
なぜInterfaceを使うのか
- 抽象化の境界: 実装の詳細を隠蔽できる。HHVMはインターフェース越しにメソッドを呼び出す際、vtable（仮想関数テーブル）を用いたディスパッチを行う。
- セキュリティの防御線: 型チェッカー（HHVM TypeChecker）は、インターフェースを実装していないクラスを確実に弾く。これは堅牢なドメインモデルを構築する際の必須要件だ。
—
3. シニアのための設計基準：境界線を見極める
どちらを選択すべきか。迷ったときは以下の3つの指針を適用せよ。
指針1: データの「ライフサイクル」と「カプセル化」
データが単なる「静的な状態」であり、他のシステムとの境界（APIの端点など）で変換されるだけなら、Shapeを選択せよ。逆に、そのデータが内部で状態を持ち、ロジックを保護する必要があるならば、迷わずClass/Interfaceを選択せよ。
指針2: HHVMのJIT最適化への寄与
HHVMはクラスのメソッド呼び出しに対して、インライン展開（Inlining）やデブライゼーション（Devirtualization）を積極的に行う。複雑なロジックをShapeに対する関数呼び出しで解決しようとすると、型チェッカーが構造を追うために複雑になり、結果としてJITが効果的な最適化を行えない「型パズル」に陥る。
指針3: 変更に対する耐性
- Shapeは「拡張」に弱い: 構造が変われば、それを参照している全ての関数シグネチャを修正する必要がある。
- Interfaceは「拡張」に強い: 新たな実装を追加しても、既存のインターフェース契約さえ満たせば、呼び出し側は一切の変更を必要としない。
—
4. 結論：極限の現場におけるトレードオフ
私が大規模システムを設計する際、以下のようにルールを設けている。
1. 境界層（Boundary Layer）: JSONのデコードやDBからの取得データは、`shape`（または`readonly shape`）で定義し、即座にドメインモデルへ変換する。
2. ドメイン層（Domain Layer）: システムの核心ロジックは、必ず`interface`と`class`で構築する。これにより、コンパイル時の静的解析の恩恵を最大化し、HHVMが生成する機械語の質を担保する。
「Shapeは速いが、守りきれない。Interfaceは重いが、支配できる。」
Hackの型システムを使いこなすということは、コンパイラに「どの程度厳格に設計を監視させるか」をコントロールすることに他ならない。この境界線を理解した時、君の書くコードは単なるスクリプトから、堅牢なエンジニアリングの結晶へと昇華されるはずだ。
次は、HHVMの型検査器がどのようにして再帰的なジェネリクスの深さを解決しているのか、その内部アルゴリズムについて議論するとしよう。深淵を覗く準備はできているか？