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

# 開催概要

* 日程: 2022/10/22 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

# 読書メモ
## 7.1_ロールを理解する_抽象を抽出する_p.189_193
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1033260289585594380

### 感想

- 順当にリファクタリングしたなー、くらいのセクション
- 慣れているとストレートにこういうコードに落ち着いたりするので、ここまでの右往左往はなんだろうなー、くらいにも感じるところ
- 「慣れていない人」向けに、とりわけ「同じコードが必要だ → コピペするしか……」な人や「同じコードが必要だ → クラス継承だ」みたいな人に対して違う方法を提示する、みたいな視点ではありそう。（和訳タイトルだけど）一応「入門」だし。

### 疑問

> MechanicとVehicleもまた、このロールを担うので、この 振る舞いを必要とします。ですから今度は、コードを再構成し、クラスが異なっても振る舞いを共 有できるようにしていきましょう。 - p.189

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1033267348259483738)
- 「同じロールを担うなら、同じ振る舞い（≒実装）が必要である」というのが、どの程度一般に許容できるのか、本書の土俵に乗った上でもやや疑問。前節では「同じ実装を持つなら、同じロールである」としていたが、それが仮に真だとして、その逆も真とは限らないが……。 :thinking_face:
- 実装内容についてというよりは、「ロール」という概念に対する本書の取り扱いに対する疑問 :+1:
- 著者の中では「同じロールを担う = 同じ振る舞い（実装）を持つ」ぐらいの認識でいる？
- 「A → B（が真）である」と主張しつつ同時に「B → A（が真）である」と主張しているのを無矛盾に整合しようとするなら、そう解釈するしかない
- だとすると、「同じロールを担うが、その根拠となる情報が異なるので、詳細な振る舞い（実装）は異なる」というケースを排除することになるが、「ロール」という概念の扱いについて、それで良いのかは疑問。
- そういえば、そもそも `#lead_days` も具象クラスでオーバーライドしているのだから、「同じロール = 同じ実装」はこの時点で本書自らも否定した格好になっている :+1:
- 「同じロールなら、同じ振る舞い（I/F）を持つ」ならそれは是として良いと思う
- この節では「振る舞い（？）を共有するため」と言いながらmoduleによるmixinを持ち出しているあたり、ここで言う「振る舞い」はI/Fではなく実装を指していると解釈できてしまうし、実際そうした解釈の方が自然
- 好意的に解釈すれば「今回はI/F実現のために必要な実装は全部同じなので、moduleによるmixinで良いからmoduleを使っているだけ」という解釈も取れなくはなさそうではあるが、この解釈を是とする根拠になるテキストは無い = 読者の好意的な妄想

## 7.1_ロールを理解する_メソッド探索の仕組み_より正確な説明_p.194_197

### discord開始地点

https://discord.com/channels/432531367427964929/898843794101911622/1033278145744338985

### 感想

- 継承と同様に、moduleをincludeすると、moduleは上位の階層として扱われることが分かった。
- 正直ここまで話すなら普通にメモリの話をしたほうが良いのでは（静的領域・ヒープ・スタックなど）
- 急に入門者をふるいにかけ始めた感 ^^; < p.198

> 自身で実装していないメ ソッドをSchedulableが呼び出すと、MountainBikeのインスタンスから見ると混乱を招くようなエラーが生じます - p.196

- 実際にやってみた
- 「Hogeクラスでメソッド未定義です」というエラーになるのを指して「混乱を招くようなエラー」と言っている？

module Scream
  def scream
    shout + ", " + say + "!!!!!!"
  end
end
class Parent
  include Scream
end
class Hoge < Parent
  def say
    "hoge"
  end
end

h = Hoge.new

puts h.scream # `scream': undefined local variable or method `shout' for #<Hoge:0x00007f9df3186558> (NameError)

- include はモジュールを探索パスに追加するだけなので、後付けで定義したメソッドもちゃんと追加される。 :+1:

#!/bin/ent ruby

module X
  def x
    puts "X#x"
  end
end

class C
  include X
end

pp C.new.methods
## => [ :x, .... ]

module X
  def z
    puts "X#z"
  end
end

pp C.new.methods
## => [ :x, :z, .... ]

### 疑問

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

### 感想

### 疑問

---

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

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

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

- 意図しているのか分からないけれど、曖昧に/雰囲気で書いてあるがゆえに、意図を問いただしたくなるところがちょいちょいあって、なかなかスムーズに読めない。
- 本書の「ロール」は眉につばつけながら読むぐらいで良いかもしれない(^^;
- 「ロール」に限らず……。 :ne: :innocent:
- 久々過ぎて死んだ
- :innocent:
- メソッド探索の流れで「module定義は後付でも良い」というのを初めて知れた
- 1ファイルで複数クラス/moduleを定義する時、内部向けの定義をファイル下方に押しやれるというのは個人的に嬉しい
- moduleを外部からrequireする時にも、requireのタイミング考慮が不要になる、みたいな効果も考えられるかも。が、この仕組を前提にして好き勝手な場所でrequireするのが良いかというとそれはそれ(^^;

### 疑問点

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

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