諸言：なぜあなたのトレイトは「型破り」なのか
HHVM/Hackのランタイムと型チェッカー（hh_client）の深淵へようこそ。
PHPの世界における「Trait（トレイト）」は、単なるコードのコピペ（水平的コード再利用）の道具に過ぎなかった。しかし、Hackにおけるトレイトは、それとは一線を画す。もし君が、トレイトの中で `$this->doSomething()` と書き、そのメソッドが「将来的にこのトレイトをインポートするクラスにあるはずだ」という漠然とした期待（あるいは祈り）に基づいたコードを書いているなら、それはプロフェッショナルとは呼べない。
Hackの厳格な静的型付け（Strict Mode）において、トレイトは「自身がどのようなコンテキストで利用されるか」を表明する権利を持っている。それが `require extends` と `require implements` だ。
この記事では、単なる文法の説明を超え、大規模なプロダクション環境において、なぜこの制約が堅牢なアーキテクチャの屋台骨となるのかを解説する。
—
1. トレイトの「契約」：`require` 制約の真意
トレイトは単体ではインスタンス化できない。そのため、トレイト内の `$this` は、デフォルトでは「何者でもない」。
ここで `require` キーワードを用いることで、トレイトに型としての境界条件を課すことができる。
`require extends`
そのトレイトを使用するクラスが、特定のクラスを継承していることを強制する。これにより、トレイト内で親クラスの `protected` メソッドやプロパティに安全にアクセスできるようになる。
`require implements`
そのトレイトを使用するクラスが、特定のインターフェースを実装していることを強制する。多重継承が許されないHackにおいて、特定の振る舞い（Interface）を持つクラスに対してのみ機能（Trait）を注入する、極めて強力な設計手法だ。
—
2. 【実践】非同期API連携における「監視可能」なリポジトリ設計
具体的なユースケースを考えよう。すべてのAPIリポジトリに「ロギング」と「リトライロジック」を注入したいが、それらは「BaseRepository」を継承し、かつ「LoggerInterface」を実装しているクラスでなければならない、という制約を設ける例だ。
/
interface ObservableEntity {
public function getEntityId(): int;
}
/
- すべてのリポジトリの基底クラス
/
abstract class BaseRepository {
protected function getConnectionName(): string {
return ‘default_master’;
}
}
/
- [The Core Logic]
- require 制約を用いたトレイト
/
trait RepositoryAuditTrait {
// このトレイトをuseするクラスは、必ずBaseRepositoryを継承し、
// 且つObservableEntityを実装していなければならない。
require extends BaseRepository;
require implements ObservableEntity;
/
- 非同期で監査ログを記録する
/
public async function logAccessAsync(string $action): Awaitable
// require extends により、BaseRepositoryのメソッドが型安全に呼べる
$conn = $this->getConnectionName();
// require implements により、自身がgetEntityId()を持つことが保証される
$id = $this->getEntityId();
// 冗長な method_exists や type assertion は一切不要。
// 型チェッカーが、このトレイトをuseする時点で整合性を検証済みだからだ。
echo “Audit: [{$conn}] Entity ID {$id} performed {$action}\n”;
// 実際にはここで非同期IO（HHVMのASIO）を呼び出す
await \HH\Asio\usleep(100);
}
}
/
- 正しい実装例
/
final class UserRepository extends BaseRepository implements ObservableEntity {
use RepositoryAuditTrait;
public function getEntityId(): int {
return 12345;
}
public async function findUserAsync(): Awaitable
// 安全にトレイトのメソッドを呼び出せる
await $this->logAccessAsync(‘FETCH’);
echo “User data retrieved.\n”;
}
}
/
- 誤った実装例（型チェッカーがエラーを吐く）
/
/
final class InvalidService {
use RepositoryAuditTrait; // ERROR: InvalidService must extend BaseRepository and implement ObservableEntity
}
/
なぜこれが「美しい」のか
1. 自己文書化: `require` 句を見るだけで、このトレイトがどのコンポーネント群の一部として設計されたかが一目でわかる。
2. 実行前検証: `hh_client` を走らせた瞬間に、設計ミス（継承忘れ、実装漏れ）が発覚する。本番環境での `Fatal error: Call to undefined method` は過去の遺物となる。
3. LSP（リスコフの置換原則）の維持: トレイトが要求する制約が明確なため、基底クラスの振る舞いを壊すような不適切なミックスインを未然に防げる。
—
3. HHVMアーキテクチャ上の利点とパフォーマンス
HHVM（HipHop Virtual Machine）のJITコンパイラにとって、型情報は最適化のガソリンだ。
トレイトに `require` 制約があると、型チェッカーはコンパイル時にクラス階層を完全に解決できる。もし制約がなければ、HHVMは「この `$this->foo()` はどこから来るのか？」を動的に探索（Dynamic Lookup）しなければならない可能性がある。
`require extends` を用いることで、メソッドのVTable（仮想関数テーブル）のスロットを静的に特定しやすくなり、結果としてディスパッチの高速化に寄与する。これはマイクロベンチマークでは微々たる差かもしれないが、数百万リクエストを捌くプロダクション環境においては、CPUサイクルの節約に直結する。
—
4. テクニカルリードとしての助言：アンチパターンを避ける
コードレビューで以下の兆候を見逃してはならない。
- 過剰な `require`: トレイトに5つも6つも `require` が並んでいる場合、そのトレイトは「責務を抱えすぎ」だ。それはトレイトではなく、抽象クラス（Abstract Class）として再定義すべきではないか？
- 循環参照: トレイト A がクラス B を要求し、クラス B がトレイト A を使う……。これ自体は許容されるが、依存関係が複雑になりすぎると、HHVMの型チェック時間が肥大化する原因となる。依存は常に「具体的」から「抽象的」へ向けるべきだ。
—
結論：規律が自由を生む
Hackにおける `require extends` と `require implements` は、自由奔放なトレイトに「規律」を与えるための強力なツールだ。
「何でもできる」コードは、保守フェーズにおいては「何も確信が持てない」コードへと成り下がる。トレイトに制約を課すことは、一見不自由に見えるが、その制約こそがリファクタリングへの勇気と、バグに対する絶対的な防御壁を提供してくれる。
君の次のプルリクエストでは、そのトレイトに魂を込め、明確な制約を記述してほしい。それが、HHVMと共に歩むエンジニアとしての「誠実さ」というものだ。