※この記事は、個人技術ブログ CodeArchPedia.com の技術メモ（要約）です。
現場でPHPを書き続けていると、どうしても関数の引数や戻り値がnullになりがちなケースに遭遇します。特にレガシーなコードや、外部サービスとの連携部分では、nullチェックが煩雑になりがちで、うっかりミスからTypeErrorが発生するリスクが付きまとっていました。
何が起きたか（課題）
Null許容型（オプショナルタイプヒント）を導入する前は、以下のような問題が発生していました。
- 関数のシグネチャを見ただけでは、引数が
nullを受け入れるのかどうかが不明瞭だった。 - 引数が
nullを許容するのかどうかをドキュメントやコメントで別途確認する必要があった。 -
nullチェックの記述が冗長になり、ロジックが追いづらくなっていた。 - 必須ではない引数に
= nullを設定しても、型ヒントとの整合性でPHPがエラーを出す場合があり、柔軟な設計が難しかった。
どう解決したか（概要）
PHP 7.1以降で導入されたNull許容型（オプショナルタイプヒント）を活用し、コードの契約（コントラクト）を明確化しました。具体的には、型名の前に疑問符（?）を付与するアプローチを採用しました。
例えば、引数や戻り値がint型またはnullである場合に?intと記述します。これにより、関数定義を見ただけで、その値が欠けていても安全に処理できる設計意図が伝わります。
また、Null合体演算子（??）と組み合わせることで、null時のフォールバック処理を一行で記述できるようになり、煩雑なif ($value === null)ブロックを大幅に削減できました。DIコンテナ利用時にも、オプションの依存サービスを安全に受け入れられるようになりました。
効果（Before/After）
Null許容型を適切に導入した結果、コードの堅牢性と保守性が大きく向上しました。
- 可読性の向上: 関数シグネチャだけで、どの引数がオプションであるか即座に把握できるようになった。
-
TypeErrorの激減: 開発者が意図的に
nullを渡しても安全な設計となり、予期せぬ実行時エラーが減少した。 - 設計の柔軟性向上: 後方互換性を保ちながら、引数にデフォルト値を持たせたり、DIでオプションサービスを導入したりする際の制約が緩和された。
具体的には、オプション設定の引数定義が、冗長なnullチェックから、Null合体演算子を使った簡潔なフォールバック処理へと移行しました。
🚀 詳細な設定とコードはこちら
具体的なNull合体演算子との組み合わせ例や、フレームワークでのDI利用時のベストプラクティス、そして設計上の注意点に関する詳細なコードスニペットは、元のブログで公開しています。