執筆者
M.N.
PHP開発者のためのSOLID原則再入門
PHPカンファレンス2025の振り返り、第5回です。
SOLID原則……名前は聞いたことある、なんとなく知っている、でもちゃんと説明できるかと言われると自信がない。
そういう状態でこのセッションに臨みました。
当日のメモに「SOLID原則など『エンジニアなら知ってて当然』みたいな知識も割と抜けてたりしたので、知識不足を反省……」と書いてあって、当時の自分が恥ずかしくなります。
SOLID原則がもたらす価値と
まず、SOLID原則をなぜ学ぶのか、という話からセッションは始まりました。
SOLID原則を守ることでもたらされる価値として挙げられていたのは以下の3つです。
1. 安定性・安全性
2. 拡張性・変更容易性
3. テスト容易性
一方で、代償もある。コストの増加と、匙加減の難しさです。
原則を適用するには設計の手間が増えますし、どこまで適用するかのバランスを誤ると、過剰に複雑なコードになってしまいます。
「銀の弾丸ではない」という前提を最初に置いているのは、好感が持てるスタートだと思いました。
DRY原則との関係
SOLIDに入る前に、DRY原則（Don't Repeat Yourself）の話がありました。「SOLID原則を理解する上でDRY原則の理解は不可欠」とのことです。
DRY原則は「コードの重複を避ける」という認識で使われがちですが、正確には「知識の重複を避ける」ものだという説明がありました。
同じ処理を2箇所に書いているからDRY違反、というシンプルな話ではなく、「同じ知識（ビジネスルール、ロジック）が複数の場所に散らばっている」ことが問題の本質だということです。
この区別は自分の中で曖昧だったので、すっきりしました。
S：単一責任の原則
1つのクラスや関数に、機能をいくつも詰め込まない、という原則です。
処理が複雑になるだけでなく、「安易に使い回す」ことで影響範囲が広がりすぎて、怖くて修正できなくなる、という話が印象的でした。
「修正が怖いコード」には心当たりがある方も多いのではないでしょうか。
あれの原因のひとつが、責任の詰め込みすぎにあるわけです。
このあたりから少し難度が上がります
L：リスコフの置換原則
リスコフの置換原則は、継承を使うときに守るべきルールをまとめたものです。
・メソッドの事前条件を増やさない（入力の制約を親より厳しくしない）
・メソッドの事後条件を増やさない（戻り値・オブジェクトの状態を親より制限しない）
・オブジェクトの不変条件を変えない（常に満たすべき条件・ルールを変えない）
・例外の種類を増やさない
まとめると、
「継承時に守るべきルールを徹底することで、拡張しやすく壊れないようにする」ということです。
リスコフの置換原則は次の第6回（プロパティフックの記事）でも再登場するので、詳しくはそちらで改めて触れたいと思います。
I：インターフェース分離の原則
用途別の小さなインターフェースに分けて定義する、という原則です。
大きなインターフェースをひとつ用意するのではなく、それを使う側が必要なものだけを実装できるように小さく切っておく。
使わないメソッドの実装を強制されない設計、と言い換えることもできます。
D：依存性逆転の原則
上位モジュールは下位モジュールから何もインポートしてはならない、という原則です。
上位（ビジネスロジック）でインターフェースを定義し、下位（技術的な実装詳細）にその実装を記述することで、関心の分離と疎結合が促進されます。
これは前回の記事で触れたDI（依存性注入）の話とも直結しています。
「DIは純粋関数型になれないオブジェクト指向言語の武器」というフレーズをセッション②で紹介しましたが、その武器を使う上での設計指針がこの原則です。
シリーズを通して読んでいただくと、各セッションのつながりが見えてくるのが面白いところです。
振り返ってみての所感
当時のメモには「聞いたことある、だけじゃダメですね」と書いていました。
SOLID原則は名前だけ知っている状態から、「なぜそれが必要か」まで腹落ちした状態になれたセッションでした。
1年経って改めて振り返ると、SOLID原則の各項目は「知識として知っている」状態と「設計判断に使える」状態の間に、結構な距離があると感じています。
セッションで整理してもらったことで、コードレビューや設計を議論するときに「これはOCP的にどうか」「責任の範囲が広すぎないか」という言葉が出やすくなった気はします。
次回は、「モブワークによるSECIモデルの実践」についてレポートしたいと思います。
お読みいただきありがとうございました。
