オブジェクト指向設計実践ガイド読書会 - 第35回
===
###### tags: `オブジェクト指向設計実践ガイド読書会`

# 開催概要

* 日程: 2022/09/10 Sat 15:00〜17:00
* 会場: https://discord.com/channels/432531367427964929/898843794101911622
* [README](https://hackmd.io/sSmTRzcQSCuvqiO7uDUkFg)
* [タイムキーバー用テンプレート](https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw)

## 課題図書

『オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方』(Sandi Metz 著, 髙山泰基 訳, 技術評論社)

- 技術評論社, pdf版あり
- https://gihyo.jp/book/2016/978-4-7741-8361-9
- Amazon
- https://www.amazon.co.jp/dp/B01L8SEVYI

## 実施要領

- 事前読書なし。都度その場で読んで、感想を書いて、議論する、を繰り返す。
- 参加スタイルは自由形。チャットでも音声でもご自由に。
- 主催はチャット参加です。

## タイマーについて
時間管理はタイマーbotで行います。
VCチャンネルに入っている人を対象にメンションが飛ぶので、VCチャンネルへの参加をお願いします。
また、タイマーは終了時に **音声がなる** ので、ご注意ください。

## 当日までの準備
1. 課題図書を手元に用意する
- 買う、借りる、etc(?)
2. 当日までに読んだり読まなかったりする
- 当日その場で読むので、事前に読んでおく必要は無し
- 気になったら事前に読んでおいても良し

---

# 当日の進行
## 進行フロー
https://hackmd.io/sSmTRzcQSCuvqiO7uDUkFg?view#%E9%80%B2%E8%A1%8C%E3%83%95%E3%83%AD%E3%83%BC

## :goti: or :okawari: について
- 各パートごとに :goti: or :okawari: を投票する.
- :okawari: が1つでも有れば、パートを続行する.

## 開催コール
https://1.bp.blogspot.com/-YrhlmWQ4uIQ/UrlmxoUdDeI/AAAAAAAAcLw/M6VFUKHnTos/s400/text_start.png

## タイムキーパー募集
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%AD%E3%83%BC%E3%83%91%E3%83%BC%E5%8B%9F%E9%9B%86

## 読書パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E8%AA%AD%E6%9B%B8%E3%83%91%E3%83%BC%E3%83%88

## 投票パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E6%8A%95%E7%A5%A8%E3%83%91%E3%83%BC%E3%83%88

## トークパート
### 議論(:thinking_face:)パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E8%AD%B0%E8%AB%96%E3%83%91%E3%83%BC%E3%83%88

### 任意トーク(:+1:)パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E4%BB%BB%E6%84%8F%E3%83%88%E3%83%BC%E3%82%AF%E3%83%91%E3%83%BC%E3%83%88

### 次回繰越(:eyes:)パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E6%AC%A1%E5%9B%9E%E7%B9%B0%E8%B6%8A%E3%83%91%E3%83%BC%E3%83%88

## 終了コール
http://3.bp.blogspot.com/-zgTNWF_hBmI/UZYlh9RhuDI/AAAAAAAATQ8/dymPl5P4eAs/s500/undoukai_relay_animal.png

# 読書メモ
## 6.6_まとめ_p.178
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1020578445756997693

### 感想
> 正しい抽象を特定するのが最もかんたんなのは、存在する具象クラスが少な くとも3つあるときです。 - p.178

- 抽象化の材料になる具体ケースが多いとより安定した中小を抽出しやすい、というのは、それはそう
- まあとはいえ、「同じルールを守らなくてはならない」とか「同じ手順を踏まなくてはならない」みたいなケースでは、2個しか無くても抽象クラス（や、時にはtrait・mixin）を使うこともある :+1:
- まあその場合、具体例が少ない分脆弱な抽象である可能性は高いので、一元化したい部分の抽出にとどめて全体をあまりガッチリ作らないことは多い
- この段階からガッチリ作るとあとで見落としが出てきて「早すぎる抽象化」になりがちですよね :sorena:
- 抽象にガッチリ枠組みを設けるか、ピンポイントな抽出に留めるか、というときの指標として「具象がいくつあるか」というのを用いるのは、有効なケースが多そう
- 具象クラスを三つ、というのは自分も近い感覚を持っているかもしれない。
- 実際には二つしか無いけどスーパークラスで抽象化しようとするときは、「仮に」三つめがあるとしたらどういう関係になるだろうか、という思考実験を軽くしながらやっていることがある。 :+1: :+1:

> p.178: 抽象スーパークラスは、テンプレートメソッドパターンを使うことで、その継承者に専門的に 特化するよう促します。

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1020583968296415283)
- ただし、サブクラスがスーパークラスのメソッドをどのように利用するのかを、事前に分析できるときに限る。
- です。かきまつがい……。 :innocent:
- 「スーパークラスがサブクラスのメソッドをどのように利用するのかを」ではなく？ :thinking_face:
- コンストラクタは、super 呼んでから、サブクラスとしてのカスタマイズをするような処理になるので、これに該当しやすそうとは言えそう。
- とはいえ、テンプレートメソッドの引数がどうなるかはそのクラス系次第なので、次善に分析できるとは限らない。それが見通しきれない場合は、super 側の引数すべてを 必要がなくてもテンプレートメソッドに全部転送する、というようなことになりやすく、引数過剰になるのはいまいちとも言える。

> サブクラスがsuper を送る必要性が取り除かれるので、階層構造の各層間の結合度が低減し、変更にも強くなります。 - p.178

- 一時期、「全然superのメソッドやプロパティを触らなくても継承使って良いのだろうか」と悩んだ時期があった（途中から全然気にしなくなった）けど、むしろ、superを使いまくる = より強く親に依存するということになるのはその通り.「superを触ると結合度が上がる」という観点がきちんと言語化されていたのは良い. :+1: :+1:

> 適切に設計された継承の階層構造は、たとえアプリケーションについてあまり詳しくないプロ グラマーでもあっても、新たなサブクラスを用いてかんたんに拡張できます。この拡張の容易さ が、継承の最も大きな強みです。 - p.178

- 実際、Webの仕組みとかHTTPの仕様とか詳しくなくても、とりあえずControllerとかを継承して自分のやりたいことを一通り書けば、とりあえず動くWebアプリケーションぐらいは作れてしまうアレ. WebやHTTPの仕組みに一切触らずに「HTTPリクエストを処理するWebアプリケーション」ができあがる（ようになっている）。 :+1: :+1:

### 疑問

## 7.1_ロールを理解する_ロールを見つける_p.179_182
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1020586110839169084

### 感想
> たとえば、 FastFeet社が成長して、リカンベントマウンテンバイクが必要になったとき、どんなことが起こる でしょうか。 - p.179

- 「リカンベント」ってなんだったっけ……てなる（なった） :aruaru:
- > 自転車の種類であるリカンベント（recumbent）を追加する場合を考えてみましょう。リカンベン トは、車体が低く、長い自転車です。乗る人はシートにもたれるように座ります。この自転車は速 いうえに、乗る人の腰と首にとってやさしいものです。 - p.165

> p.180: 7.1 ロールを理解する

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1020594728300982303)
- 初っぱなから、訳者さんがんばえー、という気持ちになるなど。何を伝えたいのか分かりにくいなー。 :thinking_face:
- ボトムアップに構成していこうとするアプローチでの説明だからかしら。トップダウンに分析・設計するアプローチだと、違う観点から必要性を説明できそうな気もするがどうだろう。
- Preparerといったロールが抽出された経緯はここまで確かにボトムアップなのだけれど、ロールの説明としては逆にトップダウンっぽく説明した方が単純になる気がする
- 「Preparerというロールを担うオブジェクトは、Preparerのインタフェースを実装する必要があります」ぐらいで、p.180-181の頭までであれこれ書いていることはカバーできてしまいそうだが、果たして...
- わかりやすさというだけでなく、ボトムアップなアプローチだと、得てして、責務ではなく単なる共通コードの括り出しに陥ってしまう懸念もある。

> pp. 180-181: ロールを見つける

- 「ロールを見つける」というタイトルの割に、ロールを見つける話をしていない。 :sorena: :point_left: :crab:
- すでに見つけていたPreparerについて「実はこれってロールなんだよ」と言い出した後、延々とロールの性質や立ち位置や（Rubyでの）活用方法を説明しているだけで、タイトルから期待した「（未知の、まだ気づいていない）ロールを見つける」話はしてなくて、アレ、となってる
- Preparerというロールがあるなら、それに対応するPreparableも存在するかもよ、というのはギリギリ「ロールを見つける」話っぽくはある
- あえて言うなら「ロールという概念を見出す/に気付く」を意図したタイトルと邪推できなくもないけれど、どうだろ。
- 原文だと「Finding Roles」で、まあ、あまり事態は変わらない(^^;

### 疑問

## {読書範囲}
### discord開始地点

### 感想

### 疑問

---

# ふりかえり
- 感想/次回の課題それぞれで5分
- 要望に応じて :okawari:

## 感想
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E6%84%9F%E6%83%B3

### 気づいたこと、気になったこと
- ロールについて、本書は初手から誤謬やらかしてそうだなとなりつつ、それはそれとしてロールについての認識や理解を改めて言語化する契機になったのは良い :+1: :+1:
- なんなら、自分がこの誤謬をやらかす前に他の人のやらかしを見て、誤謬であることを把握できた :zany_face: :zany_face:
- 文章の読解・書き方や、より適切な文章としてはどうあるべきかという点で議論ができたのは、書籍の内容からはやや脱線ではあるけれど、ためになったのでよかった。
- よくこの書籍の輪読会に参加していて初心者・ジュニア寄りのエンジニアから「わかりにくい」という声をよく聞いていたのでそれの原因が言語化されたのがよかった(小並感)

### 疑問点

### 仕事に活用してみたいこと

## 次回の課題
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E6%AC%A1%E5%9B%9E%E4%BB%A5%E9%99%8D%E3%81%AE%E8%AA%B2%E9%A1%8C

[まとめ用mdに追記](https://hackmd.io/wfDfaf4nRQuPG1BYtcy_jA)

# 次回
https://hackmd.io/GxNDVM3DQh-JK2CVOBaMxw?both