単一責任の原則

solid原則メモ
毎回忘れたり、自分に馴染みきってないので整理。
もし間違っている解釈などありましたらコメントなどしていただけると助かります。

単一責任の原則（Single responsibility principle）
開放閉鎖の原則（Open–closed principle）
リスコフの置換原則（Liskov substitution principle）
インターフェイス分離の原則（Interface segregation principle）
依存性逆転の原則（Dependency inversion principle）

テキストが増えたのでそれぞれ別記事にする
 
単一責任の原則(SRP)
wikipediaより
>1つのクラスは1つだけの責任を持たなければならない。
>すなわち、ソフトウェアの仕様の一部分を変更したときには、それにより影響を受ける仕様は、そのクラスの仕様でなければならない。

単一責任原則は以下の記事がわかりやい
shkn.hatenablog.com
>後年になって、同著者の「Clean Architecture」2によって以下のように再定義されました。
>モジュールは、たったひとつのアクターに対して責務を追うべきである

上の記事にわかりやすい説明とコードがあるのだけれど、あえて自分で言語化すると、
例えばAとBに対して給与を計算するシステムがあったとして、
Aに特別なボーナスが入ったとする。
給与計算ロジックがAとBで共通化されてしまっていると、
Aにボーナスを加えるつもりで給与処理を修正するとBにまで加算されるといった不具合が発生する
(Aの給与を加算することだけ考えてしまうことだけが関心事なのにBのことまで考えないといけなくなってしまう)。

>SRPは、ソフトウェアの複雑さを増す代わりに、モジュールの責務の境界を明確にする。

同じようなロジックがそこらで見かけてしまった思わず共通化したくなってしまうが、
コードの形が似た形であっても、アクターが別であれば処理自体は分けるべき
(間違ったDRYの適用で無理な共通化をはかると原則を違反しがちになるのでそれを避けるようにしたい。備考参照)

qiita.com
>結合している役割を見つけそれらを分離する作業は、ソフトウェア設計の本質である
>注意：この原則は、クラスだけではなく、ソフトウェアコンポーネントやマイクロサービスにも当てはまります。

クラス単位で考えがちにならないようにする。

備考

qiita.com
>DRY原則を誤認しているとはどういうことなのか？最も多いのが「DRYとはコードを重複させないという意味である」と認識しているケースです。当然、コードを重複させないという部分もDRYの一部ではあるのですが、これではソースコードだけに着目しているので、OAOO(Once And Only Once)原則に近い考え方になってしまいます。

>OAOOとは何か
>厳密な定義を書かないと斧が飛んできそうですが、長文になってしまうのであえて一言で説明すると、「コードを重複させない」という原則です。まさにDRY原則の間違った解釈と同じですね
>しかしそんなOAOOでも、 ~略~ と、言われるようあらゆる状況で適用できる原則ではないと言及されています。