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

# 開催概要

* 日程: 2022/11/05 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

# 読書メモ
## 8章_コンポジションでオブジェクトを組み合わせる_8.1自転車をパーツからコンポーズする_p.205_211
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1038425969955962922

### 感想

> 最初のステップは、まずいまあるコードのことを忘れることです。 p.206 l.9

- コードの事を考えると技術に引っ張られる(具体的な「手段」)事が多いのでこの手順を踏むことは大切だと感じた。 :+1:
- 技術に引っ張られる ← 実装が「楽」な方法などに引っ張られる。

> これは大きな変更でもなく、大きな改善でもありません。しかし、このリファクタリングによって、有益なことが1つ明らかになりました。そもそも、必要だったBicycle特有のコードがいかに 少なかったのか、明々白々です。 - p.211

- 関数なりなんなりにくくりだしてまずは見通しつくようにしつつ、どこまでが共通の部分でどこからが可変な部分（可変にしなくてはならない部分）なのか把握して、その結果に応じて継承だったりコンポジションだったりを使い分ける、というのは実際によくある :+1: :+1:
- これをみて疑問に思ったことがあるのですが、プログラムの構造(繰り返しだとか)が全く同じだけど、その一部分だけ違う(呼び出すメソッドが違うなど)場合はどのようにくくりだしますか？
- ざっくり二種類のアプローチがとりあえず浮かびますね
- 一つは本書で既に用いられているようにTemplate Methodパターンを採用して、サブクラスごとに差分を実装する
- もうひとつはStrategyパターンを採用して、アルゴリズムが変わる部分を別オブジェクトに委譲する
- Strategyパターンがいまいちわかってなかったのですがこれで分かりました。ありがとうございます。 :+1:
- あとは、採用するケースはかなり限定的だけど、動的なメソッド呼び出しを利用するとか。至極内部的な切り替えがしたいだけで、意味的に「サブクラス」や「異なるアルゴリズム」を表に出したくはないときなど。
- Rubyなら `send(:method_name, params)` 、PHPなら `$this->$method($args)` 、jsなら `this[method_name](params)` みたいな
- ちなみに send よりも `__send__` を使ったほうがよかったり(なお自分も面倒臭がってよく `send` を使う :zany_face: )
- cf. https://docs.ruby-lang.org/ja/3.1/method/Object/i/send.html
- > send が再定義された場合に備えて別名 __send__ も用意されており、ライブラリではこちらを使うべきです。また __send__ は再定義すべきではありません。
- `__send__` と `public_send` を知らなかった
- 状況によるけれど、Ruby なら、メソッド引数で Proc オブジェクトをわたしてあげるとか、ループ内容を `yield` にしてブロックつけて呼ぶとかも。 :+1: :+1: :+1:

### 疑問

> コンポジションとは、組み合わされた全体が、単なる部品の集合以上となるように、個別の部品 を複雑な全体へと組み合わせる（コンポーズする）行為です。 - p.205

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1038436192825385000)
- この説明だと、UMLで言うところの集約(aggregation)とコンポジション(composition)との区別は説明できなさそうな気がする :point_left:
- そもそもUMLで言うところの集約とコンポジションというのが、（多分、ストロヴストルップによる「抽象データ型指向」的意味での）オブジェクト指向において、どの程度支配的なのか、というのは有るのだけれども
- UMLでは、ライフサイクルの観点で両者が区別されている、という理解
- だが、本書のこの説明にはライフサイクルについての言及は無い
- 例えばEvansは、DDDにおいて「集約（aggregation）」について、明らかにUMLのそれ以上の意味を与えている
- UMLで言うところの集約・コンポジションが、たかだか「UMLではそういう意味」程度にしか共有されていないのであれば、「この本ではこういう意味でコンポジション(composition)という語を使う」ぐらいで理解しておくでも、まあ良さそう（だが、その場合、UMLで言うところの「コンポジション」とは違うということは把握しておく必要がある）
- と思ったら、P.207でUMLの記法（「黒いひし形」）を前提とした説明があるのね……。UML前提の説明だとすると、うーん :point_left:

> def post_initialize - p.208

- post_initialize みたいに空実装を用意する場合、 `nil` って明示的に書く人あまり見たことないなぁ
- 自分なら実装部にコメント書いて処理や返り値は何も書かない気がする
- これ継承のサンプルコード(p.173)からそのままなのね
- `def nop; end` というトップレベルメソッドを定義して、ここの `nil` の代わりに `nop` ってすることはある。特にコンパイラ型言語だと、最適化で消えるのでよくやる。
- jsとかでも、「何もすることが無い」というのを明示できるので、 `const nop = () => {}` と定義した関数を無視して良いコールバックにわたす、みたいなことは時々やってる（パフォーマンスはさておきつつ、意味的な明白さを優先する場合）

## 8章_コンポジションでオブジェクトを組み合わせる_8.2Partsオブジェクトをコンポーズする_Partをつくる_p.211_215
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1038441521898344479

### 感想

> p.211: `Part` と `Parts` について議論するとき、クラス名に続けて「オブジェクト」と付け、必要に応じ て「複数の」と前置きしましょう

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1038448539916841060)
- 「`Parts`オブジェクト」と書かれると、`Class`クラスのインスタンスとしての`Parts`オブジェクトと紛らわしいのでやめてほしい。まじで。 :point_left:
- 訳注にもあるとおり英語特有の問題なので難しいところ :sweat_smile:
- parts が 「Partsオブジェクト」 を指すのか 「複数の Partオブジェクト」 を指すのかが英文だとすごくややこしくなっちゃう問題
- 「複数の Partオブジェクト」を持つクラスの命名はどうするのが正解なのだろうか？('PartCollection'的な？)
- 複数形の命名をするときはこの辺に気を付けないと三日後には意味不明な事になりますね…… :aruaru:
- 自分は複数形のsではなくて、XxxListという命名を脳死でえらびがち（~~data~~sheepみたいに、複数形で変化が無い単語も時々あるので）
- あんまり意識してない時は、「Partsクラスのインスタンス」という意味で「Partsオブジェクト」と言いがち。区別したい時は「Partsインスタンス」「Partsクラスオブジェクト」みたいな言い回しを使うことがある（普段使っている言語がPHPとJSなので、あんまり出番は無いのだけれど、便宜的な説明をするとき稀に）。
- datum -> data をたまには思い出してあげてください...
- oops... 例をsheepに変更しました(^^;
- 最近は、英語圏でも datas と書かれていることがあったりなかったりするご時世よ :innocent:
- 割り切って data_list とか data_array とかにすることがあって我ながらもやる

> p.212: そして、Parts オブジェクトは needs_spare をそれぞれの Part に送ります。

- で、この `needs_spare` が何をする (どのように振る舞う) ものなのか、未定義のまま出してくるの……。 :point_left:
- ここで「個々のパーツにスペアは必要だったり不要だったりする」という情報が、シレッと混入してきているアレ

> p.212: 図8.5

- [仮説](https://discord.com/channels/432531367427964929/898843794101911622/1038438501915578540) は覆された ;_; :zany_face:
- 仮説: 
- 部品を交換できないのでスペアは荷物にしかならないことが確定しましま :zany_face: :+1:
- 交換できないスペアパーツとはいったい……うごごごご

### 疑問

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

### 感想

### 疑問

---

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

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

### 気づいたこと、気になったこと
- 本書の「コンポジション」は実質「集約」、と思わせつつ、後で「集約」は「集約」で出てくるらしいことにちょっと不安（どう辻褄をあわせるのか……）:+1:
- まさかのアートオブアジャイルと被ってた（まったく気が付かず） :sorena:

### 疑問点

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

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