SOLIDの法則を体得しているかどうかを示す、な話

はじめに

こんばんわ。ちょっと時間が空いてしまいました。最近は、仕事だったら出てきそうな言葉が出てこないのを防ぐための処方箋を色々漁っています。

「博報堂スピーチライターが教える ５日間で言葉が「思いつかない」「まとまらない」「伝わらない」がなくなる本」という本を読んでいるのですが、頭の中の語彙力をキャッチアップできるように意気軒昂できそうな気になって居ます。

　その中で、ソフトウェア開発に関する単語を出そうということで「GoFのデザインパターンを10個思い出す」とかしているうちに、ソフトウェアをしっかりと（オブジェクト指向で）設計する上で重要な原則「SOLID」を思い出そうしました。ところが、それぞれの言葉の意味をちゃんと汲み取って自分の言葉で表現できるかどうか不安になってきました。そこで、それぞれの言葉の意味を思いのままに書き出しましたので、その意味に相違がないかご検討いただければ幸いです。

１．単一責任の原則

ソフトウェアを設計する上で必要なのはクラスの設計ですが、それぞれのロジックやデータを実装しているのは一つのクラスに限る（原則ではそれぞれのクラスがロジックやデータを請け負っていることを「責任を持つ」と表現しています）。

たとえば、「消費税の計算をする部分を修正してほしい」というところ、消費税を計算するためのクラスは１つしか無いという状態に持ち込む必要があります（消費税率を保持するクラスなど）。

２．オープン・クローズドの原則

とあるクラスがあるとして、機能を拡張する仕組みはオープンにし、機能を修正する際はその内部だけで行えるように設計する。 

そのためにも、単一責任にしたほうがずっと設計がしやすいわけですね。

例えば、金額の計算をするクラスAがあるとして、円やドル、ユーロで出力するための拡張を施すためのインタフェースを用意されているが、金額の計算そのものの修正はAだけ修正できるようにしておく。

３．リスコフの置換原則

基底クラスを使って実装するところは、サブクラスを使っても同じ結果になることを保証する。

オープン・クローズ原則が機能すれば、置換原則パンを焼く基底クラスAとバゲットを焼くサブクラスBがあるとすると、パンオブジェクトを使って実装している「トーストを作る」ロジックは、バゲットオブジェクトを使っても問題なくトーストが作れるようになっている。

４．インタフェース分離の原則

汎用的なインタフェースを一つ持つよりも、機能ごとにインタフェースを分けて設計する。

確かに、汎用的なインタフェースにしてしまうと、単一責任が破綻してしまいやすくなりますね

フルコースインタフェースを用意するよりも、食前酒インタフェース、オードブルインタフェース、メインディッシュインタフェース、デザートインタフェースに分けたほうが柔軟な設計ができる。

５．依存性逆転の原則

具体的な実装に依存するのではなく、抽象的な実装に依存するように設計する。

簡単に言うと疎結合で依存関係を作るということでしょうか。
もちろん、双方向依存や循環依存はもってのほかです。

消費税を計算するクラスを設計する際、消費税10%を掛けるロジッククラスを直接用いるのではなく、「消費税率を掛ける」ロジックのインタフェースを用意した上でロジッククラスを設計しておけば、食品持ち帰り用の消費税8%を掛けるロジッククラスも用意できて、臨機応変に対応できる。

さいごに

SOLIDについて一通り自分の言葉で書いてみました。正しいかどうかは、ご指導ご鞭撻の必要があると存じておりますが、このことが教養として備わってきたと実感できるようにしたいと思っております。

忌憚ないご指導よろしくお願いいたします。

参考文献