【ITニュース解説】I just want to know if there are more people thinking that SOLID is overrated and sometimes add unnecessary complexity

ソフトウェア開発において、コードをきれいに保ち、変更しやすいように設計するための指針として「SOLID原則」というものが広く知られている。これは単一責任の原則（Single Responsibility Principle）、オープン・クローズドの原則（Open/Closed Principle）、リスコフの置換原則（Liskov Substitution Principle）、インターフェース分離の原則（Interface Segregation Principle）、依存性逆転の原則（Dependency Inversion Principle）の頭文字を取ったもので、それぞれがソフトウェア設計の特定の側面における良い習慣を示している。しかし、Redditの投稿では、このSOLID原則が時に過大評価され、不必要な複雑さを生む原因になるのではないかという疑問が提起されている。この記事では、投稿者が長年の経験から感じた、SOLID原則の厳格すぎる適用がもたらす問題について解説する。

まず、SOLID原則がそれぞれどのような考え方なのかを簡単に見ていこう。 単一責任の原則は、一つのクラスやモジュールは、ただ一つの責任だけを持つべきだという考え方だ。例えば、ユーザー情報を管理するクラスは、ユーザー情報の保存や読み込みだけを担当し、画面表示のロジックは別のクラスに任せるべき、といった具合だ。これにより、変更があった際に影響範囲を最小限に抑え、コードが理解しやすくなる。 オープン・クローズドの原則は、ソフトウェアのエンティティ（クラス、モジュール、関数など）は拡張に対して開かれ、修正に対して閉じられるべきだという原則だ。つまり、新しい機能を追加する際に、既存のコードを修正することなく、新しいコードを追加するだけで対応できるように設計する。これにより、既存の安定したコードを壊すリスクを減らすことができる。 リスコフの置換原則は、プログラム中のオブジェクトは、そのサブタイプ（派生クラス）のインスタンスに置き換えても、プログラムの正しさが損なわれないようにすべきだという原則だ。簡単に言えば、親クラスを使っている場所で、子クラスに置き換えても問題なく動作するべき、ということだ。これは、継承を正しく使うための重要な指針となる。 インターフェース分離の原則は、クライアント（インターフェースを利用する側）は、自分が使わないメソッドを持つインターフェースに依存すべきではないという原則だ。巨大なインターフェースを一つ作るのではなく、クライアントが本当に必要な機能だけを提供する、より小さく具体的なインターフェースに分割するべきだ。これにより、不要な依存関係が減り、柔軟性が高まる。 依存性逆転の原則は、高レベルのモジュールは低レベルのモジュールに依存すべきではなく、両方とも抽象（インターフェースや抽象クラス）に依存すべきだという原則だ。また、抽象は具体的な実装に依存すべきではなく、具体的な実装が抽象に依存すべきだ、とも言われる。具体的には、特定の具体的な実装に直接依存するのではなく、インターフェースや抽象クラスといった「抽象」を介して連携することで、システム全体の柔軟性やテストのしやすさを向上させる。 これらSOLID原則は、一般的に保守性、拡張性、そしてコードの理解しやすさを高めるために非常に重要だとされている。

しかし、Redditの投稿者は、SOLID原則自体は良いものとしながらも、それをあまりにも厳密に、あるいは機械的に適用しようとすると、かえって問題を引き起こす可能性があると指摘している。特に、長年にわたりソフトウェア開発の現場で働いてきた経験から、その原則が悪用された具体的な事例を挙げているのだ。

投稿者は、自身が過去にデバッグ作業を行った古いコードの例を挙げている。そのコードでは、継承とインターフェースが過剰に使われており、なんと8階層にもわたる継承やインターフェースの連鎖が存在していたという。驚くべきことに、これらのクラスのほとんどは実質的に空っぽで、次のクラスをサポートするための骨組みだけが定義されているような状態だった。そして、最終的に目的の「魔法」を実行するソースコードは、たった一つの単純な割り算、例えば double myVal = a / b; のようなごく基本的な計算処理だったのだ。投稿者は、この設計が「将来に備えてコードを準備する」という意図で行われたものだと推測している。しかし、現実はその真逆で、過度な抽象化と継承の乱用は、問題解決どころか、コードの可読性を著しく低下させ、デバッグを困難にし、むしろ新たな問題を生み出す原因となってしまっていたと語っている。

この経験談が示唆するのは、SOLID原則は確かに強力な設計指針ではあるものの、それを闇雲に、あるいは杓子定規に適用することは危険だということだ。原則はあくまでツールであり、目的ではない。将来の変化に備えることは重要だが、それが過剰な抽象化や複雑化を招き、現在のコードの理解やメンテナンスを困難にするならば、それは本末転倒と言える。システムエンジニアを目指す初心者は、SOLID原則を学ぶことの重要性を理解しつつも、それらを常に「ベストプラクティス」として盲信するのではなく、実際のプロジェクトの規模、チームの習熟度、そして具体的な要件に応じて、柔軟かつ実用的に適用するバランス感覚を養うことが求められる。原則を理解し、その背景にある意図を把握した上で、適切な判断を下す能力こそが、良いソフトウェア設計には不可欠なのだ。