Hackを掌握する極限の知見：Strict Modeにおける『null』の排除 – Maybeモナド的思考による堅牢なドメイン設計
コードレビューをしていて、最もエンジニアの技量が問われる瞬間はどこか。私は迷わず「`null`との向き合い方」を挙げる。
「値が存在しないかもしれない」という現実世界の曖昧さを、そのまま `?T`（Nullable型）としてコードに持ち込むのは、静型付け言語に対する冒涜であり、思考停止の極みだ。`Call to a member function get() on null` という、幾百回と見たであろうあの例外スタックトレース。あれは静的解析の敗北を告げるアラームに他ならない。
HHVMとHackの型チェッカーは、正しく使えばランタイムエラーをコンパイルタイムに駆逐する要塞となる。本稿では、Hackの厳格モード（`<<__STRICT__>>)`)を前提に、`null`をコードベースから完全にパージし、関数型言語におけるMaybeモナド（Option型）の思想をHackのタイプシステムで極限までエレガントに実装するアプローチを伝授する。
—
1. なぜ `?T`（Nullable型）は麻薬なのか？
Hackは初期のPHPから進化し、堅牢な型システムを手に入れた。しかし、`?string` や `?int` といったNullable型は、利便性の裏で「存在しない状態の伝播」を隠蔽する。
// 悪臭を放つアンチパターン
<<__STRICT__>>
class UserAccount {
// データベースから引けなかった場合に null を返す設計
public static function findById(int $id): ?self {
// … DB query …
return null;
}
}
// 呼び出し側
<<__STRICT__>>
function process_user(int $id): void {
$user = UserAccount::findById($id);
// null チェックを強制されるが、書き忘れるとランタイムで爆発する
if ($user !== null) {
echo $user->getName();
}
}
このコードの何が問題か？
1. 意図の隠蔽: `null` が「レコードが存在しない」のか「フェッチに失敗したエラー」なのか「初期化未了」なのかが判別つかない。
2. 防御的コードの蔓延: 呼び出し側の至る所に `if ($val !== null)` というボイラープレートが散らばり、ビジネスロジックの視認性が破壊される。
ここで、関数型言語のモナド的思考の出番だ。「値が存在するかどうかのコンテナ（Option）」で値をラップし、安全なパイプライン処理を通じてのみ値を取り出す。これをHackのジェネリクスと高階関数で実装しよう。
—
2. Hackで実現する `Option` モナドの実装
プロダクション環境でそのまま使える、完璧に型安全な `Option` クラスを定義する。
Hackのジェネリクス（Generics）と不変性（Immutability）をフル活用し、オーバーヘッドを最小限に抑えた実装だ。
<<__STRICT__>>
namespace Domain\Monad;
/
- 値の存在/不存在をカプセル化する Option モナド
- すべてのNullableな返り値をこれに置き換える。
/
abstract class Option
// 具象クラスのインスタンス化を隠蔽し、ファクトリメソッドを強制する
protected function __construct() {}
abstract public function isSome(): bool;
abstract public function isNone(): bool;
// 値を取り出す（フォールバック付き）
abstract public function unwrapOr(T $default): T;
// 関数型変換 (Map)
abstract public function map
// モナディックバインド (FlatMap)
abstract public function flatMap
// ファクトリ: 値が存在する場合
public static function some
return new Some($value);
}
// ファクトリ: 値が存在しない場合
public static function none
return new None();
}
//Nullable値から安全にOptionを生成する境界防壁
public static function fromNullable
if ($value is nonnull) {
return self::some($value);
}
return self::none();
}
}
<<__STRICT__>>
final class Some
public function __construct(private T $value) {}
public function isSome(): bool { return true; }
public function isNone(): bool { return false; }
public function unwrapOr(T $default): T {
return $this->value;
}
public function map
return Option::some($f($this->value));
}
public function flatMap
return $f($this->value);
}
}
<<__STRICT__>>
final class None
public function isSome(): bool { return false; }
public function isNone(): bool { return true; }
public function unwrapOr(T $default): T {
return $default;
}
public function map
return Option::none();
}
public function flatMap
return Option::none();
}
}
—
3. 実務での応用：API連携とドメインロジックの美学
では、この `Option
以下のコードを見てほしい。`null` はシステムの外周（データベースドライバやHTTPクライアントとの境界）でのみ捕捉され、ドメイン層の内部には一切侵入しない。
<<__STRICT__>>
namespace Domain\Service;
use namespace Domain\Monad;
use namespace HH\Asio;
class UserProfileService {
// 外部APIやDBからのフェッチ境界
public static async Task
// 擬似的な外部コール。存在しない場合は null が返ると仮定
$rawEmail = await self::queryDatabaseForEmail_UNSAFE($userId);
// 境界で速やかに Option に包む
return Domain\Monad\Option::fromNullable($rawEmail);
}
public static async Task
$maybeEmail = await self::fetchUserEmailAsync($userId);
// nullチェックの代わりに、関数型のパイプラインで処理を安全に繋ぐ
return $maybeEmail
->map(($email) ==> Str\uppercase($email)) // メールアドレスがあれば大文字に変換
->unwrapOr(‘NO_EMAIL_REGISTERED’); // なければ安全なデフォルト値を返す
}
private static async Task queryDatabaseForEmail_UNSAFE(int $userId): Awaitable {
// 外部レガシーインターフェースのモック
return $userId === 1 ? “architect@hhvm.internal” : null;
}
}
この設計がもたらす圧倒的なメリット
1. 型チェッカーによる強制: 開発者は `unwrapOr` や `map` を通すことを強制されるため、`null` ポインタ例外の発生余地がコンパイル時に完全にゼロになる。
2. コンポーネントの合成可能性 (Composability): 非同期処理（`Awaitable`）とモナドの組み合わせにより、複雑な分岐ロジックを排除した宣言的なコード記述が可能になる。
—
4. HHVMアーキテクチャの観点からのパフォーマンス考察
「こんなオブジェクトをラップしまくるクラスを作ったら、メモリとアロケーションのオーバーヘッドでHHVMのJITコンパイラが悲鳴を上げるのではないか？」
優秀なテックリードであれば、ここで当然の疑問を抱くだろう。しかし、そこはHackとHHVMの深淵を理解していれば杞憂だと分かる。
1. JITコンパイルと型の最適化: HHVMの優れたトレーシングJITは、`Option
2. プリミティブのボックス化回避: Hackのジェネリクスは、PHPのような単なる動的型の隠れ蓑ではなく、HHVMのレイヤーで厳密に型情報として保持される（※一部の特殊なケースを除き、タイプヒントはネイティブな最適化を受ける）。
ただし、極限のミリ秒を争うホットパス（例：数百万回ループするインメモリの配列処理など）においては、オブジェクト生成のコストをゼロにするために、あえてプリミティブな条件分岐にフォールバックする判断もアーキテクトとしては持っておくべきだ。だが、一般的なWebアプリケーションのドメイン層やサービス層においては、可読性と保守性の向上がもたらす開発スピードの爆発的な向上効果が、わずかなオーバーヘッドを完全に凌駕する。
—
5. 結び：コードの品格を保つために
`null` を排除するということは、単にバグを減らすという矮小な目的のためではない。それは、「この変数が取りうる状態」をエンジニア自身が完全に支配しているという、コードベースに対する絶対的なコントロールの証明である。
Hackの厳格モードと型チェッカーを信頼し、曖昧さを許さない設計を貫くこと。それこそが、世界最高峰のシステムを組み上げるエンジニアリングの極意である。
次回のコードレビューで `?` が付いた変数を見かけたら、こう問いかけろ。
「おい、なぜここにモナドを使わない？」 と。