# ちょうぜつ本_読書py[3] みんなのメモ
###### 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[3] のメモです
https://pythonista-books.connpass.com/event/291125/

読む範囲： 5章

## 読書会の流れ

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

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

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

### 第5章 オブジェクト指向原則 SOLID

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

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

- みんな、SOLIDってどれを一番意識しているんだろう？ :+1: :+1:
- 私は単一責任の原則を意識しつつ、「何が単一だろう」っていうところが難しいなぁと思ってます
- この章は学びしかなかったです。オブジェクト指向とはなにかの解説を求めてさまよい、しっくり来る知に至った感覚
- コラムの巨人の肩に乗るもなるほど感
- SOLID原則に沿ったコード、PythonのProtocolでインターフェースを表現できるのか考えたい:+1::+1:
- 今回の写経はインターフェースを抽象基底クラスで実装しました
- 『ロバストPython』のインターフェースの章によるとTDDへの言及があり、使用の最小単位インターフェースは次章と関わってくるのか〜と期待
-
-

### 5-1

-
-
-

### 5-2

- 設計の恣意性の話（開発者の都合に無理やり意味づけ）が目からウロコだった
- そういうことか！ [「同時に変更しないものは別のファイルに分けて書きなさい」の前提である「同時に変更」の意味を読み飛ばすと、ひとつの変更意図があちこちのファイルに飛び散りますね。「分けなさい」は「同時に変更するなら同じファイルに書きなさい」と同じ意味です。#ちょうぜつ本 には SRP の例を 2 つ書きました](https://twitter.com/tanakahisateru/status/1631601623184330754):+1:
- DBへのwriteがDataInputで、DBからのreadがDataOutputの最初は逆では？と思ったけれど、このケースはこれでいいのだな
- UNIXの「ひとつのことをうまくやれ」とはまた似て非なるものだと最近教わりました :+1:
- https://twitter.com/t_wada/status/1397709987388874752?lang=ja
-

### 5-3

- ジェネリックFizzBuzz、お見事:+1
- 3つのルールを順にmatchしたらapplyで実装できるのがきれいですごい （写経した感想）
- このコード、すごいなぁと思いました（小並感
- 同意する一方、どこら辺から意識するか・・・みたいなことが実務というか、実際には大事なんだろうなぁと思ってます
- YAGNI原則的な観点と、認知負荷の観点で
-

### 5-4

- リスコフ置換原則は、下位互換性の話だった！:+1:
- 元のクラスと違う動きをするコードは結構見てましたが、原則に則るとNGなんですね
- 何でアカンねやろと思って調べてた:+1::+1:
- https://qiita.com/yuki153/items/142d0d7a556cab787fad#%E3%83%AA%E3%82%B9%E3%82%B3%E3%83%95%E3%81%AE%E7%BD%AE%E6%8F%9B%E5%8E%9F%E5%89%87%E3%81%AB%E9%81%95%E5%8F%8D%E3%81%97%E3%81%A6%E3%81%AF%E3%81%84%E3%81%91%E3%81%AA%E3%81%84%E7%90%86%E7%94%B1
- 後は原則に違反したらいけない
- ではどうすべきなのか？みたいなところはどうなんだろう:+1:
- 別のクラスを定義する？
- 元のクラスを作り直す？
- 後はこんなブログも見つけました。:+1:
- http://marupeke296.com/OOD_No7_LiskovSubstitutionPrinciple.html
-

### 5-5

- インターフェースは小さく！:+1:
- 私は複数の使用をごっちゃにしたひどいコードを書いてきました札を下げねば
- データ型にみんなが等しくアクセスするわけではない
- 利用側からは概念が**部分的に**しか見えない！（ハッとした）
- 身の回りのものを見てもたしかに部分的にしか見えない（この節のイラスト）:+1:
-
-

### 5-6

- 安定したものに依存させよう、という考え方がなかなか学ぶまでなかったんですよね:+1:
- 一方、最近は認知的な負荷としてはどうなんだろう？みたいなところも考えたりします
- 長いこと何言ってるか分からなかったんですが、インターフェースに依存するんだ（インターフェースは安定抽象なんだ）と気づいたらすっと飲み込めました:+1::+1:
- Software Design 2023/06 のクリーンアーキテクチャ特集
- 飲み込むまではインターフェースってなんかかっこいいから作るんだと思っていた
- DIP(依存性逆転の原則)を守っていない話 https://blog.ojisan.io/not-use-dip/ を見かけました:+1:
- 一休のito naoyaさん「[これ500%ぐらい同意](https://twitter.com/naoya_ito/status/1684349407268048896)」:+1::+1:
- めちゃくちゃ同意してる（気になる
-
-