# ちょうぜつ本_読書py[7] みんなのメモ
###### 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[7] のメモです

https://pythonista-books.connpass.com/event/300078/

読む範囲：8章(8.1-8.3)

## 読書会の流れ

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

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

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

### 第8章 デザインパターン

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

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

-
-
-

### 8-1

- 過去に紹介した気もするけど、デザインパターン周りの会話は fukabori.fm がお勧め :+1: :+1:
- fukabori.fm/episode/48
- fukabori.fm/episode/49
- いつできたものだったか？歴史的な話もある
-
-

### 8-2

- Iteratorはfor文の裏にある概念。気づかなくてもプログラミングできるけど、気づくと世界の見え方が変わる:+1:
- PHPのTraversableはPythonだとIterableじゃないかな :+1:
- そして、PythonではIteratorはIterableの子クラスとして実装している
- 型ヒントはIterableと書くんだ！！（オンメモリのlistも無限のIteratorも表している抽象概念）:+1:
- ちょうぜつ本としてはデザインパターンは名前と概念を理解しようというスタンスなのかなと思いました（Iteratorは名前と概念の理解を示す一例にすぎない）:+1::+1:
- これはあまり出くわさないけども、要は反復ロジックを抽象化して外だししたものって感じ？だとしたらIterableを実装したものとセットで使わないといけないんだろうな。:+1:
- ちょうぜつ本でのデザインパターンの説明は確かにちょっと違いそうな気がする
- 抽象を扱えることのメリット（語彙が適当か怪しい）について説明をしていたので目から鱗
- 他、コード単位で違いそうなポイントとしてはforeachでの例に留めているところかな？（Pythonでいうfor文）
- foreachの内部では「次があるか」とチェックしているはずだと思っているけど、コードでそういうふうには書いてはないんだなと
- Iteratorはデータ構造を意識しないで、反復することだけに関心があるので、データ生成を動的に行ったりデータ生成に時間がかかる場合でも利用側は意識をしなくて済むのが反復を抽象化しているメリットの1つだと思いました　:+1: :+1: :+1:
- `next`がfor文の内部で使われているんで良いんだっけ :+1: :+1:
- https://docs.python.org/ja/3/library/functions.html?highlight=next#next
- `yield`をreturnするときに型ヒントで`Iterator`って書いた（mypyでErrorになったから）けど、知らなかった概念が増えて楽しかった印象 :+1: :+1:
- そして`Iterable`と書く方が好ましいのかな

### 8-3

Template Method

- 穴埋め問題って、うまい説明！
- インターフェース定義するのうまい！:+1: :+1:
- Template Methodで吸収できないケースが後から発生し苦しんだことがあるが、インターフェースを定義していたら吸収できていたな〜と

- Template Methodの例、DjangoのGenericViewが浮かびました :+1:
- TemplateはDjangoのTemplateみたいなものが該当するのかな・・・？

- 正直、最初の頃はStrategyの方が安全。徐々に「なんかこの部分必ず概念としても共通コードとして出てきてね？毎回ここのコード実装すんのテスト検証コストも踏まえて考えると無駄があるから楽したいわーー」て欲が、共通化したことによる変更範囲っていうリスクを上回ってるなと確信を持てるまでは、使うべきではないパターンな気がする。要は変更容易性っていう品質観点から徐々に再利用っていう品質観点に移行してきたときにはじめて考えればいいって思ってる。あくまでもinterfaceがあった上で自分たちで実装する側で抽象クラス定義してって感じ。:+1: :+1:
- Template Methodパターンによる実装継承は雛形としてコーディングの生産性を上げるためのものであり、抽象として利用するのは別のもの(今回ではRequestHandlerInterface)であると理解しました

Bridge

- Bridgeを知らなかったばっかりにTemplate Methodでゴリ押ししてごめんなさい :+1:
- 複数のhas-aで考えるの、なるほどすぎた
- Pythonは多重継承できる言語なのでBridgeは実は出番が少ない？
- mixinで書いてみた（伸びしろ豊富） https://github.com/ftnext/transcendent-book-py/blob/cacc5e7f972fd81d7fad017441b4245b3c382d48/chapter8/bridge_by_mixin.py :+1:
- Bridgeしなくてもできちゃった https://github.com/ftnext/transcendent-book-py/blob/cacc5e7f972fd81d7fad017441b4245b3c382d48/chapter8/naive_instead_of_bridge.py :+1:
- BridgeはMixinが近かったりする・・・？
- Brigdeの説明を聞いてて、誤った例のようなことはやっちゃいそうだなーと思った :+1:
- このパターンは抽象度を揃えたSLAP原則を守っていないといけない気がするkudo :+1: