やあ。Hackの深淵へようこそ。
HHVMのJITコンパイラが吐き出す機械語の響きと、型チェッカーが鳴らす警告音を子守唄のように愛するエンジニアなら、一度は「Traitの柔軟性と、クラス継承の厳格さの狭間」で悩んだことがあるはずだ。
今日は、Hackにおける『Traitの制約（`require extends` / `require implements`）』という、一見地味だが、実は大規模開発の設計を劇的に変える強力な武器について語ろう。
—
なぜTraitに「制約」が必要なのか？
Traitはコードの再利用性を高めるための強力なツールだ。しかし、無計画にTraitを乱用すると、あるクラスでしか使えないメソッドを他のクラスでも呼び出そうとして、実行時にエラーを吐くという「動的言語時代の悪夢」が蘇る。
Hackの`strict`モードは、そんな不確定要素を許さない。「このTraitを使うなら、必ずこのクラスを継承（または実装）していなければならない」という契約（Contract）を型チェッカーに強制させる仕組み。それが `require` 制約だ。
イメージで捉える「制約」
Traitを「パーツ」だとすると、`require` 制約は「接続コネクタの形状」だ。
- 素のTrait: どんなクラスにもくっつく（接着剤がない）。
- require制約付きTrait: 特定の形状（基底クラス）を持つクラスにしか接続できない（ロック機構付き）。
これにより、Trait側で「自分は必ず特定のメソッドを持っているはずだ」という前提でコードを書けるようになるんだ。
—
実践：require extends で「安心感」を確保する
まずはコードを見てみよう。特定の基底クラスを継承していることだけを保証するパターンだ。
<<__ConsistentConstruct>>
abstract class BaseLogger {
abstract public function log(string $msg): void;
}
trait DatabaseLogger {
// ここが魔法の制約
// このTraitを使うクラスは、必ずBaseLoggerを継承していなければならない
require extends BaseLogger;
public function logToDatabase(string $msg): void {
// コンパイラは、BaseLoggerにlogメソッドがあることを知っている
// だから、ここでlog()を呼んでも型エラーにならない！
$this->log(“Database: ” . $msg);
}
}
// 成功例: BaseLoggerを継承しているのでOK
class UserRepo extends BaseLogger {
use DatabaseLogger;
public function log(string $msg): void {
print $msg . PHP_EOL;
}
}
なぜこれが強力なのか？
もし、`BaseLogger` を継承していないクラスで `use DatabaseLogger;` を書くとどうなるか？
HHVMの型チェッカー（`hh_client`）は、コンパイル時に容赦なくエラーを吐く。
> `Error: This trait requires that the class using it extends BaseLogger.`
これが「型システムの重み」だ。実行時に「メソッドが見つかりません」というエラーで落ちるリスクを、開発の設計段階で完全に排除できる。
—
require implements：インターフェースによる疎結合
次は `require implements` だ。これは「継承」ではなく「能力（インターフェース）」に依存させることで、より柔軟な疎結合を実現する。
interface IIdentifiable {
public function getId(): int;
}
trait AuditTrail {
// このTraitは、IDを取得できるクラスにならどこでも使える
require implements IIdentifiable;
public function printAudit(): void {
// IIdentifiableを実装していることが保証されているので、getId()を安全に呼べる
print “Audit for ID: ” . (string)$this->getId();
}
}
この設計なら、`User`クラスでも`Order`クラスでも、`IIdentifiable`さえ実装していれば、共通の監査ログ処理を安全にミックスインできる。クラス階層（継承）に縛られず、「その機能を持つべき性質」にフォーカスできるのがHackのモダンなところだね。
—
陥りやすい罠：やってはいけないこと
初学者がよくやるミスを挙げておこう。
1. 制約の連鎖: Trait A が Trait B を `require` し、さらにそれを継承関係で制約する……と複雑になりすぎて、型推論の迷路に迷い込む。基本は「1つのTraitにつき1つの責務」だ。
2. 実行時の「なぜ？」: 「Traitの中で `self::` を使いたいのにエラーになる！」という場合、それは制約が足りていない証拠だ。Traitは独立した存在ではなく、あくまで「ホストクラスの一部」として解釈されることを忘れないでほしい。
—
まとめ：Hackを掌握するということ
Hackの静的型システムは、ただ厳しいだけではない。「正しい設計を、強制的にサポートしてくれる」ための仕組みなんだ。
- `require extends`: クラスの「血統」に依存し、親の機能をフル活用する。
- `require implements`: クラスの「能力」に依存し、柔軟な疎結合を作る。
この2つを使い分けることで、君のコードは驚くほど堅牢になり、リファクタリングの恐怖から解放されるはずだ。
「型はドキュメントよりも雄弁である」。
この言葉の意味を、ぜひ日々の開発で噛み締めてみてほしい。さあ、次はどんな複雑なアーキテクチャをHackで構築しようか？またいつでも聞きに来てくれ。