# ちょうぜつ本_読書py[1] みんなのメモ
###### tags: `ちょうぜつ本`

- このメモはWebに公開されています（HackMDチーム）
- リンクを知っている人は見られます
- HackMDにログインして編集できます

## ちょうぜつ本

- [ちょうぜつソフトウェア設計入門 ――PHPで理解するオブジェクト指向の活用](https://gihyo.jp/book/2022/978-4-297-13234-7)
- [サポートページ](https://gihyo.jp/book/2022/978-4-297-13234-7/support)（正誤表）

## お願い事項

(1) 今を楽しもう（録画はしないでね）

(2) 本メモは**インターネット上に公開されています。**
そのため、文章の丸写し（!=引用）や、書籍を読まずに内容が詳細に分かる表現は行わないようにしましょう。

参考記事:

- [Qiita ヘルプ 著作物を引用する際の注意点
](https://help.qiita.com/ja/articles/about-copylight)
- [Qiitaで記事を公開するときに気を付けるべきマナーについて 〜無断でネットや書籍の内容を丸写しするのはやめよう〜
](https://qiita.com/jnchito/items/215c2d51599eb29adabc)
- [文化庁 著作物が自由に使える場合
](https://www.bunka.go.jp/seisaku/chosakuken/seidokaisetsu/gaiyo/chosakubutsu_jiyu.html)

## このメモについて

このメモは ちょうぜつ本_読書py[1] のメモです
<span style="color: red">https://pythonista-books.connpass.com/event/286950/</span>

読む範囲：2章

## 読書会の流れ

* 20:00〜20:30 **自由参加**のもくもく会（個人作業）
- 事前に読む時間がとれなかった方はここで読んじゃいましょう（ざっとで大丈夫です）
- 合わせて、この**HackMD**に話したいことを各自書いてください
- ログインすれば書ける設定にしています
- ここがわからん、ここはわかった　お気軽に書き込んでみてください
- HackMDの書き込みに投票し、みんなが気になるところをわいわい読み解いていきます
* 20:30〜22:00 読書会本編（みんなでわいわい）
* Discordでスライド共有して別途案内します
* 20:30開始の本編では、「わたしこれ気になる！」
という話題に `:+1:` と書いて投票します。
* :+1: する上限はありません。
気になる話題に全部 :+1: しちゃいましょう。
ただし1つの話題には1個だけ:+1:でお願いします
* 票数が多い話題から話していきます。

## 以下、もくもく会ワークゾーン

以下は各節で「これってどういうことなんだろう」「ここからこういう気付きがあった」などを書き出すゾーンです。

### 第2章 ›› パッケージ原則

_章よりも細かい目次は公開されていないようですが、読書会運営都合により見出し番号だけ記載しています_

章全体への書き出しはこちらに

- パッケージ原則、全部初めて知りました
- 同じく！
- 閉鎖性共通原則からやった方が時系列でのまとめ方の流れが把握しやすいと思います。
-

### 2-1

- JavaのIterableとIteratorが異なるコンポーネントに配置されてるのもこれが理由？:+1::+1::+1:
-
- ライブラリについて特定バージョンの全てを使うか使わないかを普段やっているわけだから、言われてみればたしかに　:+1::+1:

### 2-2

- キーボードの例が分かりやすい気がする
- 分かりやすいと思いました
- 混ざっているものを分ける大変さ、最近お気に入りの例はカレーライス🍛。ひさてるさんのツイートで見た覚え（メモリーさんの本にあるらしい）
-
- 再利用される頻度って観点で見ると、常にモニタリングしてて「なんかこいつらは同時に使われてんのに、これとこれは使われてないな～」てものを明らかにしておくことで、再利用パーツの利用者の観点から見たら、いちいち何を使えばよくてとか気にすることなく使いやすい。「この範囲で同時に再利用されます。」て範囲のものを事前に明らかにした上で境界を引きまとめてるが、大体どのくらいの変更が入りにくいなていう安定度合いで再利用に踏み込んでるのかまでのざっくり定量評価まではやったことないな。インターフェイス分離原則の言い換えってのはすごいわかりやすい。:+1::+1::+1:
- クリーンアーキテクチャ本に書かれてる「密結合していないクラスはそのコンポーネントにまとめるべきではない」ってあるけども、密結合してれば一部しか再利用なんて選択することにもならない。

### 2-3

- キーボードの例がここもわかりやすい
- 最初はしのご言わずにこれ目指す　以上　その中でも同じ変更理由だと思ってたけどモニタリングしてて「あれ？ここは仮説通り同時に修正されてるのに、こことここは修正されてないな」てものが段々明らかになってくる。そしたら境界線の再検討。同時に変更が全然入らないような箇所も明らかになってくるから、そしたら徐々に再利用性を安定してる所から考え出すのだと予測してる。:+1:
- いきなり再利用性を取るのはマジで危険。個人的には再利用性は保守性とは分けて考えてる。再利用性を優先すると、変更がしにくくなる変更コスト跳ね上がるからトレードオフ関係にある。:+1::+1:

### 2-4

- クラスの循環参照も危険ですね。:+1:
- 循環はしていないものの、サードパーティライブラリで１つをアップデートするのに他のライブラリもそれに伴って上げないといけない事があるなって思い出しました:+1:
- そういえばPythonには循環参照を回避するweakrefというものがありますね:+1:
-

### 2-5

- 依存性逆転原則とこれはセットで学習して初めて理解が深まりました。:+1:
-
-

### 2-6

- プログラミング言語自体やサードパーティのユーティリティライブラリも抽象
- 最近PyDanticがv1からv2に上がり破壊的変更があったのですが、PyDanticには（ユーティリティとして）依存したくありつつも、追従しないといけないのはどうなんだろう（抽象に使うべきではないのかな？）:+1:
- クリーンアーキテクチャの考えが出てきたというか、安定したものに依存しようという感じで理解できた・・・？:+1:
- 不安定度と抽象度の直線からの距離でチェック対象としてるクリーンアーキテクチャ本のあれの手法取り入れてるとこってどんくらいあるのだろう？　個人的には一回もあの方法は使ったことないな、、、。:+1::+1:

### 2-7

-
-
-