読書ログ | #ちょうぜつ本第5章〜SOLID原則、この章までの積み重ねと豊富なサンプルコードでこれまでで一番分かりやすかった解説！〜

はじめに

変更しやすいコードが書けないのにソフトウェア開発とか舐めているのですか
天使様¹ごめんなさい〜、nikkieです

「かわいい」と技術書が夢の合体を果たした、ちょうぜつ本（『ちょうぜつソフトウェア設計入門』）！🤗
読書会と絡めて読み進め、今回は第5章「オブジェクト指向原則 SOLID」を読みました。

前回のちょうぜつ本！

いわしまんさんの書評エントリがきっかけで、手に取りました。
3章まで読み進め、

今回は4章の読書ログに先んじて、次回読書会の範囲になっている5章の読書ログです！

SOLID原則は初見ではないのですが、サンプルコードがSOLID原則を守ることで変更しやすいコードに変わっていくさまを見て、これまでになく理解が深まりました。
各原則に関する気づきや感想を綴ります。

SRP

単一責任原則で印象的だったのは、

クラスの責務は、何かの法則で機械的に決まるものではなく、将来の保守開発への想像から恣意的に生み出すもの (Kindle 版 p.152)

設計って数学の証明みたく、置かれた文脈によらず同一の結論に達するものだと思い込んでいたのですが、恣意性！！

ここでの例は2つで

ニュース記事管理で入稿と購読は分ける
データベースドライバのreadとwriteは分けない

ドライバの例でreadとwriteを分けないのは、ドライバVer1とVer2を区別するのを優先という意思決定による！（恣意性の例）
このデータベースドライバの例も別の文脈においてはreadとwriteを分けうるわけで、「設計ってめちゃめちゃ人間臭いな〜」と実感しました。
置かれた状況まで考慮しないと設計の妥当性というものは判断できないかもしれません（設計においても圧倒的当事者意識説）

OCP

ジェネリック FizzBuzzの例！
本質を抜き出して変更に対して閉ざし、仕様は拡張に対して開きます。
本質の抜き出し方がお見事でした👏

FizzBuzzの本質に近い実装は、私がこれまで雑多なコードリーディングで見出していたものでもありました（解釈一致〜🙌）。
ちょうぜつ本で言語化を得て先へ進んでいけそうです。

ここで語られるシンプル

一貫した法則をベースに、徹底してパーツを外せるように作られたもののほうがシンプル (Kindle 版 p.163)

これはレゴブロックのような性質で（個々の形状は変更できないけれど、積み上げてどんなものでも作れる＝拡張性）、私も信奉するところです。
おすすめ記事

LSP

正しい継承について、言い換えると下位互換性。

基底クラスにない事前条件（入力値の制限など）を加えてはいけない以外に、基底クラスが持っていた事後条件（出力結果など）の範囲を逸脱するのもNGです。(Kindle 版 p.169)

型の事前条件：狭めてはならない
型の事後条件：広げてはならない

写経の中でPythonの型チェッカはどれくらいサポートしてくれるんだろうと気になりました。
mypyのドキュメントにはLSPへの言及があるのですが、
https://mypy.readthedocs.io/en/stable/common_issues.html#incompatible-overrides
使い方が悪かったのか、開発中にAnimalとCatを入れ替えても怒ってくれなかったんですよね