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

# 開催概要

* 日程: 2023/02/25 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.252_253
[前回](https://hackmd.io/UzloqiPhQs-SJDiXbAOCFA?view#92_%E5%8F%97%E4%BF%A1%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%82%92%E3%83%86%E3%82%B9%E3%83%88%E3%81%99%E3%82%8B_%E3%83%91%E3%83%96%E3%83%AA%E3%83%83%E3%82%AF%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9%E3%82%92%E8%A8%BC%E6%98%8E%E3%81%99%E3%82%8B_p252_253)からの引き継ぎ

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

### 感想
> p.253 この問題を生み出す結合はGearの内部に隠されています。
- 「テスト=ドキュメント」とは言えない例になりそう？ :+1:
- この、内部が密結合になっているパターンはどうやって防げば良いのだろうか。テストを書いてリファクタリングしやすくする程度でしか対策できないのか？ :eyes: :thinking_face:
- そもそも気にしなくて良いケース、というのもあるのではと思う :+1:
- 密結合な「内部」が完全に内部に閉じていて、オブジェクトの外からは全く関知の術が無いケースとか
- この場合、密結合な「内部」はインターフェースによって完全に隠蔽された詳細でしか無いので、使う側がいちいち気にすることではない:+1:
- 下手に分離して疎結合にすると疎結合にするメリットよりデメリットの方が上回りそうですね。（このメリットが密結合になっているべき理由といえそう？）
- 少なくとも、気にしなくていいケースであることすら判別が難しい場合もあると思うので、クラスの内部構造を表現する何か(できれば図)は作っていた方が良さそうですね。 :+1:
- 「気にするべきものを気にしない作りになっている」ならともかく、「気にしなくていいものを気にしている」という場合、詳細な依存がすでに露出しているということだろうから、「内部構造を表現する何か」というよりは、「公開された構造を表現する何か」を見直せば良い、とになりそうな？
- その上で、「内部構造を表現する何か」を作るとしたら:
- 内部によほど複雑な機構を隠しているとか、一見して必然性がわからないが理屈を知ればその必要性がわかるとか、テキストのみでは理解が難しい背景がある場合には図示などを残しておいても良いかもしれない
- が、そうでもなければあくまで内部の仕組みでしか無い以上、単純なものならそこまでする必要も無いのでは、とも思う。単純に、図に起こす手間もあるので（要するに、必要なら残すしそうでないなら残さないという、ありきたりなアレ）
- 内部の密結合を気にし始めたら、外のライブラリ使うのすら「ライブラリ依存」って言って怖くてできなくなりそう。 :+1:
- 密結合であるべきでない密結合を、コードの再利用以外で検出するとしたら: :+1:
- クラス・オブジェクト間の依存関係を図に起こして、想定していなかった依存関係になっていないか確認する
- 設計の前提となったドメインやユースケースを確認して、それらを実現するための妥当な設計になっているか確認する
- とか？
- 確認した結果、密結合になっているべき理由があるなら、それはそれでOKだと思う

### 疑問
> p.252: 受信メッセージは、その実行によって戻される値や状態を表明することでテストされます。

* テストと表明は同じものと見てよいのか? 目的が違うような。 :eyes:
* テストは能動的に検査するのが目的
* 表明は受動的に異常が生じないようにガードするのが目的 :naruhodo: :+1: :+1: :+1:
* assert を 表明 と訳すのに違和感...単純な英和としては良いのだけど。 :sore:
* 目的の違いだけでなく、テスト目的で表明を書くということになり、表明が過剰な使われ方になり、本来の目的で書かれた表明がごみになりそう。
* ここでの「表明（assertion）」、プログラミング言語の機構やプログラミング手法としてのassertionではなくて、テストでassertって書いているのを以て「表明（assertion）」って言ってる？ :kamo:
* いやまあ確かにassertという語ではあるのだけれど、プログラミングの文脈で不用意に「表明（assertion）」って語を使われると↑で言われているようなそれと区別が一見してつかない（し、現状推測するしかなくなってる）ので、ちょっと脚注ぐらいは欲しかったなー感
- > Incoming messages are tested by making assertions about the value, or state, that their invocation returns
- 「表明」はまんまassertionかー (・皿・

> p.253 Wheelの作成コスト

- 作成コストとは何を指しているのだろう？ :thinking_face: :eyes:
- よくみたら、最初に2つの問題点を挙げるときは「1つはテストの実行時間です」と書いているのに、次の段落では「Wheelの作成コストが高い場合」となっていて、途中で実行時間→作成コストにすり替わっているのか :+1: :+1:
- 内部的に依存が多いと作成コストが上がるという程度の話なんですかね。
- ↓の通り、また実行時間の話に戻っているので、主眼がどっちなのか（どっちもなのか）、謎…… :innocent:
- 「作成コスト」と「実行時間」を同一視しているとか？~~ハハハ御冗談を~~
- 作成コストの高いオブジェクトを生成するコードは実行時間が長くなる、ということで、ここにおいては包含関係かと。 :+1:
- ここで言う「作成コスト」が「作成自体に処理時間がかかる（e.g. テストデータを読み込んで〜）」を指すのだとその通りだと思いつつ、パラメータの種類や組み合わせが多くて「望むオブジェクトを作るためのコードを書くのが面倒」というケースも「作成コスト」にあたらないかな、と
- 自分が最初に連想したのは後者のコストだったので、「よくわからん」ってなりました
- あー、でもまあ、前後では「実行時間」ばっかり言及しているあたり、この本では「作成コスト」として後者をそもそも念頭に置いていない感じですかね。 :+1:
- 「望むオブジェクトを作るためのコードを書くのが面倒」
最初これだと思いました。でも、「文脈的にこんなのでてこないよな？ん？？？？」となった感じです。 :handshake:
- そしてさらに次の段落では「テストは、最低限のコードを実行する場合に、最速で終わります」とあって、また実行時間の話に変わってる……
- 作成コストの原文: If Wheels are expensive to create, the Gear test pays that cost even though it has no interest in Wheel.
- 作成コストは訳の過程で出てきただけの言葉で、「手間」という意図くらいで良いのかも。(後続の文で that cost という言い方はしてますが) :naruhodo: :+1:

## 9.2_受信メッセージをテストする_テスト対象のオブジェクトを隔離する_p.254_256
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1079026293355593828

### 感想
> Gearを独立してテストすることの難しさによって、Gearが特定のコンテキストに結びつけられており、しかも制限を強要し、再利用の妨げとなるコンテキストに結びつけられていることがわかるのです。 - p.254

- 著者は「独立してテスト」ということにえらく執心しているが、独立していることが必ずしも是ではないというのは、前節の感想でも触れている通り。ただ、GearとWheelの例では、記載の通り分けた方が良いだろうというのは同意
- （この本では）ギアがgear_inchesを決定するのは組み合わされるWheel（ないし、Diameterizable）との関係においてであって、rimやtireといったWheelの詳細は必ずしも必要無いため
- 最近読んでいる「単体テストの考え方/使い方」の第2章で古典学派とロンドン学派の「隔離」の考え方の違いについて書かれていたけどここで著者が気にしている「独立してテスト」はそれとはまた別？ :thinking_face:

### 疑問

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

### 感想

### 疑問

---

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

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

### 気づいたこと、気になったこと
- この本の感想ではないが、積んでいた『単体テストの考え方/使い方』へ期せず手を伸ばすことになった~~、ラッキー(ry~~ :sorena:
- 本書の著者は（恐らく）ロンドン学派っぽい
- スタンスがわかった上で読むのとよくわからない上で読むのとでは、割り引くべきかそうでないかの判断が変わってくるので、大事（なので、著者にはちゃんと表明してほしかった） :+1:
- 結果として、著者がなにゆえここまで「独立」という表現を強調し、またその観点からばかり話をするのか、その理由も見当がつくようになってきた（いささか原理主義的な匂いは感じる :point_left:）
- 最近ちょうど読み始めていた『単体テストの考え方/使い方』から疑問・ディスカッションがつながってよかった(小並感) :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)

# 次回