はじめに
人生初ライブ現地がAct-3でよかった〜！ 最高だったよ〜！！ にっPです（今日は仕掛け人モード）
ちょうぜつ本_読書pyで『A Philosophy of Software Design』が話題に挙がりました（後述するClassitis）。
存在は知っていて永遠の積ん読という存在だったのですが、待ってても邦訳は出なさそう1、英語自体は平易ということでエイヤッと4章だけ読みました。
読んで理解したことをバックアップします
目次
4章「Modules Should Be Deep」
ソフトウェアの複雑さ（complexity）を扱う（manageなので、なんとかする）テクニックを扱った章の1つです。
modular designというテクニックについてで、肝は「Modules Should Be Deep」
modules
modular design
- 相対的に独立したモジュール群からソフトウェアシステムを構築する
- モジュール間の依存を最小化する
- 依存（dependency）
- 例：モジュールAはモジュールBの関数を呼び出す
- ＝他のモジュールについて開発者が知っている必要がある部分
- 依存（dependency）
モジュールを2つの要素で考える
- interface
- implementation（実装）
- モジュールがどのようなコードか
モジュールとは（例で列挙）
- オブジェクト指向言語では
- クラス
- クラスのメソッド
- オブジェクト指向でない言語では
- 関数
- より高次のサブシステムやサービス
書籍での議論はクラスについてだが、高次のモジュールについても適用可能
deep
deepなモジュールとは、パワフルな機能を持ち、かつ、単純（simple）なinterfaceのモジュール
- deep 縦に長い長方形
- 縦に長い＝十分な機能を提供
- 一番上の辺が短い＝単純なinterface
- shallow 横に長い長方形
deepなモジュールの例
著者はdeepなモジュール（クラス）推しなので、「クラスは小さくあるべき」というアプローチに警鐘を鳴らしている
- 個々の単純なクラス群を作ってしまう（Classitis）
- 末尾のitisは「症」とか「狂」という意味みたいです（ウィズダム英和辞典）
- 小さなたくさんのクラスは、システム全体の複雑さを増加させるという主張
t-wadaさんによる解説
以下のスライドの理解が深まりました
fukabori.fmにもあるみたいです
終わりに
『A Philosophy of Software Design』4章でdeep modulesという概念を知りました。
これに関しては思うところもあるので、近日中にアウトプット予定です（ライブで源Pみたいに感情爆発してしまったので、1記事にまとめきれず🙏）
