PHPカンファレンス2025参加レポート⑦「PHP 8.4の新機能『プロパティフック』から学ぶオブジェクト指向設計とリスコフの置換原則」

2026.09.15

執筆者

M.N.

プロパティフックを知る、学ぶ

PHPカンファレンス2025の振り返り、第7回です。
今回は「PHP 8.4の新機能『プロパティフック』から学ぶオブジェクト指向設計とリスコフの置換原則」というセッションについてです。

タイトルが長いですが、前回のSOLID原則の記事でも「詳しくは次回」と予告したリスコフの置換原則が、このセッションでいよいよ登場します。
PHP8.4の新機能を題材にしながら、設計原則の話に展開していく、という構成でした。

PHP8.4で追加された「プロパティフック」は、プロパティの値の読み書きにフックを仕込める機能です。

・setフック
　プロパティに値をセットするときに自動で実行される処理

・getフック
　プロパティの値を読み込むときに自動で実行される処理

Laravelを使ったことがある方には、EloquentのアクセサーやミューテーターがほぼPHP言語組み込みになったもの、と説明するとイメージしやすいかもしれません。

なぜこの機能が必要なのか、という話もありました。
readonlyプロパティなど、オブジェクトを安全に扱うための対応はPHP8系で少しずつ進んでいましたが、書き方が統一できていないデメリットがありました。

プロパティフックはその解決策のひとつとして設計されている、という背景です。

プロパティフックには、2種類のプロパティがあります。

・バックドプロパティ
　実際に値を持つプロパティ（例：半径）

・仮想プロパティ
　他の値から算出されるため、実際の値を持たないプロパティ（例：面積）

半径を持つ円オブジェクトを例にすると、半径はバックドプロパティとして実際の値を保持します。
面積はgetフックで半径から都度計算するため、値を持つ必要がない仮想プロパティになります。

この使い分けがコードをすっきりさせる鍵になりそうです。

セッションではここから設計原則の話に展開していきます。

まず、
「整数」クラスを継承して「自然数（0以上の整数）」クラスを作る例が示されました。
setフックでバリデーションを追加することで、自然数の制約（0以上）を継承先で実装できます。
両方ともint型なので、型の互換性は保たれます。

一方で、
「数」クラスを継承して「整数」クラスを作ろうとすると、型が変わってしまうためうまくいかない、という例も紹介されていました。
この「うまくいかない」理由の説明として、リスコフの置換原則が登場します。

以前のSOLID原則の記事でも触れましたが、改めて整理します。

リスコフの置換原則（LSP）は、「継承関係において、子クラスは親クラスの代わりに使えなければならない」という原則です。
言い換えると、子クラスに置き換えても親クラスと同じように動くことが保証されていなければならない、ということです。

セッションではこれを「共変」と「反変」という概念で説明していました。

◆反変（入力・引数）
引数の型は、親クラスより広くすることはOKだが、狭くしてはいけない

◆共変（出力・戻り値）
戻り値の型は、親クラスより狭くすることはOKだが、広げてはいけない

つまり「受け取れる入力を絞ってはいけない」「返せる出力を広げてはいけない」というルールです。

先ほどの「整数→自然数」の例で言うと、setフックでバリデーションを追加することで入力の制約が増える（0未満を受け取れなくなる）ため、厳密にはリスコフの置換原則に抵触する可能性がある、という話でした。

プロパティフックで変性を扱えるようになった
セッションのポイントとして、「プロパティフックの導入によって、プロパティが変性（共変・反変）を持てるようになった」という話がありました。

これまでPHPのプロパティは変性を持てず、継承時に型を変更することができませんでした。
プロパティフックの登場で、getフック・setフックの型を個別に制御できるようになり、設計の表現力が上がった、ということのようです。

このセッションは、PHP8.4の新機能という具体的な入り口から、オブジェクト指向設計の本質的な話に展開していく構成が面白かったです。

「プロパティフックを使えばこう書ける」という機能紹介で終わらず、「なぜそう設計すべきか」「どこに落とし穴があるか」まで掘り下げていたのが印象的でした。

リスコフの置換原則については、SOLID原則のセッションと合わせて2回聴講したことで、ようやく自分の中でイメージが固まってきた気がします。
「子クラスは親クラスの代わりに使える」という一文は短いですが、継承を設計するときの判断軸として、頭に置いておく価値がある原則だと感じています。

次回は、「イベントストーミング図からコードへの変換手順」についてレポートします。