八葉の日記

日々、感じたことをまとめる場として利用する

SOLID原則:1つ目 単一責任の原則(SRP:Single Responsibility Principle)

〇まえおき

ソフトウェアの開発に携わっっている方なら、ひどいコードの保守にあたって、
心身がとても疲れた経験はあると思うし、自分が作ったコードが人を大変な目に
会わせたことはあるんじゃないかと思います。
それらのコードは作ったときはヒドイコードではなかったんですが、
その後、数年をかけて徐々にひどくなっていったんじゃないかと思っています。

「ひどくならないようにオブジェクト指向というやつを利用したのに」
ということを言ったり聞いたりすることがありますが、中々に難しいので、
オブジェクト指向の有名な原則であるSOLID原則をまとめてみようかと思います。

ちなみに難しくなる理由なんですが、最初にソフトウェアを作ったときに
予期していなかった機能をむりやり追加することがほとんどです。
だから、変更を許容する設計が必要になるのですが、そのためのコツが
SOLID原則にまとめられていると思います。


〇単一責任の原則(SRP:Single Responsibility Principle)
クラスを変更する理由は1つ以上存在してはならない。

これはクラスは1つの役割を持つように作りましょうということです。1つの役割のみ持っているなら、
変更の理由も(1つの)役割の変更になるので、自然と上記の原則は守られます。

例えば、データを取得して、画面に表示するようなソフトを作りたいとします。
乱暴にやると次のように設計できます。
f:id:konboi_kun:20171111171026p:plain

こうなると画面表示に変更が入るパターンは次の3つだと思います。
・画面表示の仕組みが変わった
 例:今までは白黒だったけど、カラーにも対応してね
・計算のルールが変わった
 例:法律、組織改革、社長の気紛れで、やり方が変わったから、
   ソフトの方も変化に追従してね
・データベースが変わった
 例:最近のはやりに合わせてRDB使おうよ。

このクラスをどれか1つの理由で変更するときは、他2つの役割に影響がないように
細心の注意をもって変更する必要があり、影響範囲の再試験が必要です。
(不具合だしてもいいなら、適当にやればいいんですが、不具合が許容される
ソフトウェアはありません。
金をとっていなくても不具合だすとクレームが来ます)

もし、元からクラス設計がSRPの原則に従っていたならば、面倒な影響範囲調査と
再試験の気苦労がなくなっていたはずです。


アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技