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

# 開催概要

* 日程: 2023/03/04 Sat 21:00〜23: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

# 読書メモ
## 9.2_受信メッセージをテストする_クラスを使って依存オブジェクトを注入する_p.256_257

### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1081551474515001415

### 感想

> このテストは、失敗するべくして失敗しています。 - p.257

- 失敗するべきときにちゃんと失敗する、というのは一つテストの重要な点である、というのは全く同意
- コードを一箇所変更したとき、しばしば予想してなかったテストまで壊れることがある.つまり、自分が想定していたより広い範囲に影響を与えるコードを変えてしまったということ.
- そこから芋づる式に変更すべき箇所が特定できるという場合もある
- 単にテストコードの方を新しくするだけ、という場合でも「このコードにはこれだけの要素が関わっている」ということを確認できる意味もある
- ~~それはそれとして、テストを更新するのは大変めんどくさいのでぶっちゃけヤダ~~
- 変更洩れに対するシグナルとしてのテスト結果。これが、リファクタリングという行為を保証するのに重要なところ。 :+1:

> 抽象を用意し、そのテストをしたほうがより効果を得られる場合も当然あるでしょう。 - p.257

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1081555604641955851)
- ここで言う「抽象」とは、何を指すのか
- ここまでのところ、筆者は概念としての「抽象」と実装としての「抽象クラス」をないまぜに語る節もあり、今ひとつ判然としないような :point_left:
- 概念をテストする、というのはあんまり意味が通らないので抽象クラスの方だったとして、その場合、基底クラスとなるようなクラスの方にテストを追加しろ、ぐらいの意味で一旦は良いのかもしれない
- （それはそれで、Rubyに抽象クラスは無いけど……という気持ちにはなる. moduleを作ってmoduleをテスト、というのを想定している？それはそれで説明文からの飛躍が大きいが……）

### 疑問

## 9.2_受信メッセージをテストする_ロールとして依存オブジェクトを注入する_p.258_259

### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1081561211805634693

### 感想
> ここでは、WheelはDiameterizableの唯一の担い手であり、現時点ではほかのものを想定していません。

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1081567216400609280)
- 現時点では小規模なのですぐわかるけど、コードが大規模になったとき、ほかのものを想定するかどうかはどのように判別するんだろう？ :thinking_face:
- 基本的には、やはり要求分析・ユースケース記述・モデリングの結果として「同一のロールを担うオブジェクトが複数必要」と見なされるかどうか、というところになるような
- 「ありうるかも」を基準にするとJavaやC#の文脈における「すべてのクラスに一つinterfaceを定義する」みたいな教条主義に陥るし、「今がこうだから」を基準にすると要求やユースケースから当然想定できるケースも考慮しない近視眼的な設計になってしまう :naruhodo:

> 図 9.4 Gear は Diameterizable に依存し、Wheel は Diameterizable を実装する

- 図9.4、矢印の使い方がテキトー過ぎでは？ :point_left:
- Wheel -> Diameterizable は依存を表した矢印になっているのに、 Diameterizable -> Gear はオブジェクト注入の流れになっている
- 両方がDiameterizableに矢印がむくと思っていたので最初わからなかった :point_left: :sorena:
- 「GearはDiameterizableに依存する」として矢印をDiameterizableに向ければ、矢印の意味も一貫したのに...
- 英語圏でありがちなミスで、「主語 → 目的語」の向きになっている。ここでの主語・目的語は、「Diameterizableは Gearに注入される」のそれ。つまり、関連の説明自体が、依存方向を説明するのに適さない書き方になっている。 :naruhodo:
- Evans本のダイアグラム、矢印が何を意味しているのかわからない箇所がちらほらあったのも同じ理由……？（そういえば、「〜される」という表現が散見されたような気も）

### 疑問

## 9.2_受信メッセージをテストする_ロールとして依存オブジェクトを注入する_テストダブルをつくる_p.259_p.261

### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1081570852220444712

### 感想
> このようなダブルはとてもかんたんにつくれます。

- こうしたオブジェクト生成と交換の気軽さは、ダックタイピングを利用する言語ならでは、という感じ
- 静的型付け & nominal typingのみだと、ちょっと面倒になることが多い（詰まるところは言語次第ではあるけれど）:+1: :+1:

> DiameterDoubleはモックではありません。気を抜くと「モック」という言葉でこのダブルを表現しがちになりますが、実際はまったく別のものです。これについては「9.4 送信メッセージをテストする」で取り扱います。 - p.260

- スタブとモックをえらい注意深く、正確に扱おうとしている！
- ~~ここ書きながら、なんか良いものでも食べたのか~~ :innocent: :kusa:
- スタブ(stub)とモック(mock)の違いは、『xUnit Test Patterns』Chapter 23に記載あり（というより、『テスト駆動開発』付録Cによるなら、『xUnit〜』によって整理された模様）

### 疑問
> このテストでは、Diameterizableのインターフェースはもともとのdiameterメソッドに戻されたとしましょう。 - p.259

- はて、なんのために width に名前を変えたのだったっけか…… :+1:
- 「失敗するべくして失敗」することを例示するためだけの例で、なんらかの要請によるものではない、架空の変更 :naruhodo:
- なので、「戻されたとしましょう」という文章がよくなくて、そんな変更は無かったものとしましょう、くらいの内容の方が誠実 :point_left:
- プラス、「widthへの変更は例のための例で、それ以上のものではありません」というのも明示的に添えておいてもらえると、読者としては「何のための変更だったの……」と無駄に悩まなくて済んで素敵

- もし`DiameterDouble`の`diameter`で返す値にバリエーションが出てくると、いつでも10を返すという事実がなくなるので、別のクラスを作ったほうが良いのだろうか？ :thinking_face: :thinking_face:

> このダブルは、diameterを「スタブ」します。

- DiameterDouble が wheel の代替になっているけれど、そこに wheel っぽい情報を何も出さないのが何なのか読み取れずにいる。Wheel を渡してるのはあくまでDiameterize させたいためで、wheel っていう途中経過はいらないということ？ :thinking_face:
- Gearが依存している（=Gearにわたすべき）オブジェクトはここでは Diameterizable なものである、という前提があるから、WheelというDiameterizableのいち具体例を全面に押し出すべきではない、ということかと :+1: :+1:
- 例えば DBConnection といったI/Fがあって、それに依存したオブジェクトをテストしようとしたとき、テストダブルに MySQLConnectionDouble という名前をつける必要があるか、とか

---

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

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

### 気づいたこと、気になったこと

- オブジェクトの生成を外部に任せることで　具象に依存　→　抽象に依存　という移行がスムーズに行えるようになる。
- ダックタイピングが使える言語の場合、たとえテスト対象が具象に依存してようと、好き勝手にオブジェクトを注入できるのは魅力的に感じた。
- 自由度の反面、管理や制御がゆるくなるということでもあるので、そのあたりで塩梅というか扱いの難しさが有る点は要注意 :sorena: :+1:
- 今回のように、スタブを注入している場合だと、「期待している具象が注入されているか」が保証されないので注意ですね。
- nominal typing と structual typing をその時々で自由に切り替えできると一番うれしいのだけど（ワガママ
- まあ今回は本題のための前フリ、というところではあった（それはそれとして、ちょっとした記述のおかげで無用な混乱に振り回されてしまった感(^^;
- 矢印の使い方に対する「英語圏にありがちなミス」というのを知れたのは、本書ともはや関係ないけどありがたい収穫. これで、またテキトーな矢印が出たときの対処法が増えた :zany_face:
- 最後30分でも参加したら、次回の足がかりになりそうな気持ちになれた。 :tada: :clap:

### 疑問点

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

## 次回の課題
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/vpGCpaDDRYqJRN0aHMwbqA?both