2020年4月9日、木曜日。

夕飯にホットクックでぶり大根をつくった。砂糖を大さじ4杯も入れるように書いてあったけど小さじ４杯の誤植だろう、と思ってかなり減らしたけれどそれでも甘かった。みりんだけで作ればよかったかな。

ひきつづき『clean architecture 達人に学ぶソフトウェアの構造と設計』を読む。第Ⅲ部の途中から。

• 第9章: LSP:リスコフの置換原則
  • （『アジャイルソフトウェア開発の奥義』からの引用で）S型のオブジェクトo1の各々に、対応するT型のオブジェクトo2が1つ存在し、Tを使って定義されたプログラムPに対してo2の代わりにo1を使ってもPの振る舞いが変わらない場合、SはTの派生型であると言える* インターフェイスだけでなく、アーキテクチャのレベルでも置換可能性を適用すべきである
  • （感想）次のnoteがわかりやすかった。 https://note.com/erukiti/n/n88b8ed99f1e1
  • （感想）「引数、返却値の型を合わせる」みたいなシンプルな理解だと誤る。RectangleとSquareの例を思い出し、「呼び出す側が想定している動作をするか」みたいな観点で考えるべき。
• 第10章 ISP:インターフェイス分離の原則
  • 必要としないモジュールに依存しないようにする
  • モジュールだけでなく、アーキテクチャレベルでも意識する必要がある
  • システムがフレームワーク、フレームワークがデータベースにそれぞれ依存すると、データベースの変更がフレームワークにもシステムにも影響する
• 第11章: DIP:依存関係逆転の法則
  • インターフェースは実装よりも変化する頻度が少ない
  • システム内の「変化しやすい」要素に依存しないようにしたい
  • そのため変化しやすい具象クラスを参照・継承しない
  • オブジェクト指向においてはAbstract Factoryパターンの利用があてはまる
  • DIPはアーキテクチャにおいても重要で、「依存性のルール」として現れる会社においても「依存関係逆転」は使えるかも。上司と部下のどちらが「変化しやすい」のかを見極めないといけないが（むしろ変化してほしい上司／部下がいたりして）。

株のプログラムの依存整理も完了。有価証券報告書の解析を関心事の中心として、これに依存させるように各モジュールを整理していった。上手くはいったけれど、まだメリットを実感するような設計にはなっていないような気がした。

またいろいろと学習を進める中で、 __main__.pyをプログラムのソースディレクトリ直下に置くことで単独のアプリケーションとして動かすことができることも理解できた。ゼロから学ぶPythonに大変助けられた。 pytestもやっと開始。 setup.py の作成がちょっと怖かったけれど、なんとか上手くいってよかった。

pip install -e .の意味はサッパリ理解していない。xbrlファイルの解析に失敗している企業が多くあったので、pytestを使いながら少し修正。いい感じに成長できていて晩酌がはずんだ。