【入門編】Hackの型システムで実現する『Value Object』の設計パターン – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

こんにちは！日々のHack言語での開発、本当にお疲れ様です。

他のプログラミング言語からHackの世界に飛び込んできたとき、あの厳格な型チェッカー（Typechecker）の佇まいに、最初は少し身構えてしまったかもしれませんよね。「なんでここまで厳しく型をチェックするんだろう？」って。

でも、安心してください。その厳しさこそが、Hackが誇る最大の武器であり、大規模なコードベースを圧倒的なスピードと安全性を保ったままスケールさせるための秘密なんです。

今回は、そんなHackの厳格な型システム（Strict Mode）をフル活用して、ドメインの安全性を極限まで高める『Value Object（バリューオブジェクト）』の設計パターンについて、徹底的に解説していきますね。ここをクリアすれば、Hackの型システムの本質が手に取るように分かるようになりますよ！

—

なぜプリミティブ型だけでは危険なのか？

開発をしていると、ユーザーの「年齢」を表すのに `int` 型を使ったり、メールアドレスを表すのに `string` 型をそのまま使ったりしがちですよね。

こんなコードを見たことはありませんか？

<<__Strict>>
namespace Hack\Community\Blog;

// プリミティブ型をそのまま使った危険な例
function register_user(string $email, int $age): void {
// 処理…
}

一見、何の問題もないように見えます。しかし、大規模なシステムになってくると、うっかり引数の順番を間違えて `register_user(25, “test@example.com”)` と渡してしまっても、実行するまでエラーに気づけない……なんてことが起こり得ますよね。

さらに、「年齢にはマイナスの値を入れちゃいけない」「メールアドレスは特定のフォーマットを満たしているべき」といったドメインのルール（制約）を、関数を呼び出すたびにあちこちでバリデーションするのは、コードの重複を生み、バグの温床になります。

そこで登場するのが、Value Objectです。

—

Value Objectとは何か？

Value Objectとは、一言で言うと「プリミティブな値を独自の型で包み込み、データとそのルール（振る舞い）を一体化させるデザインパターン」です。

イメージ図で表すと、こういう関係性になります。

[生データ] (string “user@example.com”)
↓ これを安全なカプセルで包み込む
[Value Object] (EmailAddress型)
├── 不変性 (Immutability) : 一度作ったら値は変更できない
├── 自己検証 (Validation) : 生成された時点で不正な値は絶対に存在しない
└── 等価性 (Equality) : 値が同じなら、それは同じものとみなす

Hackの厳格な型システム（`<<__Strict>>`）と組み合わせることで、このValue Objectは最強の効力を発揮します。実際にコードを見ていきましょう！

—

Hackで実装する実用的なValue Object

ここでは、メールアドレスを表現する `EmailAddress` というValue Objectを厳格モード（Strict Mode）で実装してみます。

<<__Strict>>
namespace Hack\Community\Blog;

メールアドレスを表現するValue Object

/
final class EmailAddress {
// 内部の値を保持するプライベートなプロパティ
// readonly modifierを使い、一度代入したら二度と書き換えられない（不変性）ようにします
private string $value;

private function __construct(string $value) {
// 生成時に必ずバリデーションを行う
if (!\filter_var($value, \FILTER_VALIDATE_EMAIL)) {
throw new \InvalidArgumentException(\strmsprintf(“無効なメールアドレス形式です: %s”, $value));
}
$this->value = $value;
}

ファクトリーメソッドを通じてのみインスタンス化を許可する

/
public static function fromString(string $value): this {
return new self($value);
}

ラップしているプリミティブな値を取り出すゲッター

/
public function toString(): string {
return $this->value;
}

2つのValue Objectが等しいか比較するメソッド

/
public function equals(EmailAddress $other): bool {
return $this->value === $other->toString();
}
}

このコードのポイントとHackらしい工夫

1. `<<__Strict>>` の徹底
ファイル全体を厳格モードにすることで、型推論の曖昧さを排除し、すべての変数や返り値に明確な型定義を強制しています。
2. `private function __construct` とファクトリーメソッド (`fromString`)
コンストラクタを隠蔽し、静的メソッド経由でしかオブジェクトを作れないようにしています。これにより、「不正な値を持ったオブジェクトがコードベースに存在する」という状態を型レベルで完全に防ぎます。
3. `final` キーワードによる継承の禁止
Value Objectは「値」そのものを表すため、継承によって予期せぬ振る舞いの変更が行われないよう、`final` をつけて堅牢性を高めています。
4. `this` 型（F-Bounded Polymorphism的な表現）の活用
ファクトリーメソッドの返り値に `this` を使うことで、サブクラス化（もし将来的に拡張した場合など）した際も、正しい自身の型を返すことができます。

—

実際に使ってみましょう！

では、先ほど作成した `EmailAddress` を使う側（クライアントコード）の書き方を見てみます。

<<__Strict>>
namespace Hack\Community\Blog;

function send_welcome_email(EmailAddress $email): void {
// ここに到達した時点で、$email は「絶対に正しいメールアドレス」であることが保証されている！
\printf(“ウェルカムメールを送信中: %s\n”, $email->toString());
}

// — 実行エントリポイント —
<<__EntryPoint>>
function main(): void {
// 正しいメールアドレスの場合
$myEmail = EmailAddress::fromString(“developer@example.com”);
send_welcome_email($myEmail);

// 【注意】不正なメールアドレスを渡すと、コンパイル時ではなく
// ファクトリーメソッド実行時に InvalidArgumentException がスローされます
try {
$invalidEmail = EmailAddress::fromString(“not-an-email”);
} catch (\InvalidArgumentException $e) {
\printf(“エラー捕捉: %s\n”, $e->getMessage());
}
}

実行結果例

ウェルカムメールを送信中: developer@example.com
エラー捕捉: 無効なメールアドレス形式です: not-an-email

どうですか？関数側は `string` ではなく `EmailAddress` 型を受け取るため、もう「変な文字列が渡されてこないか心配する」必要が一切なくなりました。これが型安全の恩恵です。

—

初学者がハマりやすいポイントと文法エラー対策

HackでValue Objectを設計する際、初心者がつまずきやすいポイントをいくつかピックアップしておきますね。

1. `==` と `equals` の違いに注意する

PHPの伝統的な感覚で `$object1 == $object2` と書くと、プロパティの値を比較してくれますが、厳格なHackの文脈では意図しない挙動を生むことがあります。
Value Object同士の比較は、専用の `equals()` メソッドを実装して明示的に比較するように心がけましょう。

2. 名前空間（Namespace）とオートローディングのミス

Hackの型チェッカーは非常に厳格に名前空間をチェックします。クラスが見つからないというエラーが出た場合は、大文字小文字や `use` 宣言の記述漏れがないかを真っ先に疑ってください。

—

まとめ：型チェッカーを「最高の相棒」にしよう

今回は、Hackの厳格モードを活かしたValue Objectの設計パターンについて解説しました。

プリミティブ型をそのまま使わず、ドメインの概念を型で包む。
コンストラクタを隠蔽し、不正な値の存在を許さない。
関数やメソッドのシグネチャを強固にし、バグの温床をコンパイル時（および型チェック時）に排除する。

最初は「ルールが厳しいな」と感じるかもしれませんが、この型チェッカーの厳しさは、あなたを縛るためのものではなく、将来のバグやリファクタリングの恐怖からあなたを守ってくれる最高の相棒です。

ここをマスターすれば、あなたの書くHackコードは一段と美しく、揺るぎないものになりますよ。
ぜひ、明日からのコードに取り入れてみてくださいね。それでは、また次回の知見でお会いしましょう！