おっさんが「SOLID原則」を教えてもらう話

社員会で「SOLID原則」というキーワードが出てきたけど、初めて聞いたな・・・

今日も生成AIに聞いてみよう。

ということで、今回はMicrosoft Copilotに「SOLID原則」を教えてもらおう

Copilotに、次のプロンプトを投げてみよう。

#役割
あなたはプロのシステムエンジニアです。

#タスク
以下の制約条件からSOLID原則について説明してください。

#制約条件
– SOLID原則を全く知らない人にも分かりやすい内容にする

もちろんです、SOLID原則について説明します。SOLID原則は、ソフトウェア設計の5つの基本的な原則で、より良い、より理解しやすい、より柔軟で、よりメンテナンスしやすいコードを作成するためのガイドラインとなっています。

なるほど。ソフトウェア設計の基本的な原則なのか。

5つあるということは、頭文字をとっているのかな？

それぞれ何を意味しているんだろう。

S: 単一責任の原則 (Single Responsibility Principle, SRP)
これは、「クラスは1つの責任だけを持つべきだ」という原則です。つまり、クラスが変更される理由は1つだけであるべきです。これにより、コードの再利用性とメンテナンス性が向上します。
O: オープン・クローズド原則 (Open-Closed Principle, OCP)
これは、「ソフトウェアのエンティティは拡張に対して開かれていて、修正に対して閉じているべきだ」という原則です。つまり、既存のコードは新しい機能を追加するためには変更せず、新しいコードを追加することで機能を拡張できるべきです。
L: リスコフの置換原則 (Liskov Substitution Principle, LSP)
これは、「サブタイプはそのスーパータイプと置換可能でなければならない」という原則です。つまり、基底クラスの型で派生クラスのインスタンスを使用できるべきです。
I: インターフェース分離の原則 (Interface Segregation Principle, ISP)
これは、「クライアントは不必要なインターフェースに依存すべきではない」という原則です。つまり、大きな一つのインターフェースよりも、特定のクライアントに必要な機能だけを持つ複数の小さなインターフェースが望ましいです。
D: 依存性逆転の原則 (Dependency Inversion Principle, DIP)
これは、「高レベルのモジュールは低レベルのモジュールに依存すべきではなく、両方とも抽象に依存すべきだ」という原則です。つまり、具体的な実装よりも抽象に依存することで、コードの柔軟性と再利用性が向上します。

具体例を添えて、もう少しわかりやすい説明にしてもらえるかな。

もちろんです、SOLID原則をもっとシンプルに説明しますね。

S: 単一責任の原則 (Single Responsibility Principle, SRP)
これは、「1人の料理人が1つの料理を作るべきだ」と考えることができます。1人の料理人がたくさんの料理を同時に作ると、全ての料理が中途半端になってしまうかもしれません。同じように、1つのクラスがたくさんのことをすると、バグが出やすくなったり、理解しづらくなったりします。
O: オープン・クローズド原則 (Open-Closed Principle, OCP)
これは、「お店は新しい商品を追加することはできるが、既存の商品を変更することはできない」と考えることができます。新しい商品を追加することはお客さんにとって新鮮で楽しいですが、既存の商品が突然変わると混乱を招くかもしれません。同じように、新しい機能を追加するために既存のコードを変更すると、予期しないバグを生む可能性があります。
L: リスコフの置換原則 (Liskov Substitution Principle, LSP)
これは、「スポーツカーは車であるべきだ」と考えることができます。スポーツカーは車の一種なので、車が持つ基本的な機能（運転する、ブレーキをかけるなど）を持つべきです。同じように、派生クラスは基底クラスが持つ機能を維持するべきです。
I: インターフェース分離の原則 (Interface Segregation Principle, ISP)
これは、「メニューはシンプルであるべきだ」と考えることができます。メニューが複雑すぎると、お客さんは何を注文すればいいのか迷ってしまいます。同じように、インターフェースが複雑すぎると、それを使う開発者は混乱してしまうかもしれません。
D: 依存性逆転の原則 (Dependency Inversion Principle, DIP)
これは、「電源プラグは標準化されているべきだ」と考えることができます。電源プラグが標準化されていれば、どの電気製品もどのコンセントにも接続できます。同じように、高レベルのモジュールと低レベルのモジュールが直接依存関係を持つのではなく、共通の「抽象」に依存することで、モジュール間の依存性を減らすことができます。

具体例を挙げてくれたから、イメージしやすくなったな。

これらの原則は、良いソフトウェアを作るための道しるべのようなものです。それぞれの原則が持つ意味を理解し、適切に適用することで、効率的でメンテナンスしやすいソフトウェアを作成することができます。ただし、これらの原則はあくまでガイドラインであり、すべての状況に適用できるわけではないことを理解することも重要です。適切なバランスと判断が求められます。