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

# 開催概要

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

# 課題図書

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

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

# 実施要領

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

# 当日までの準備
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

## タイムキーパー募集

今回の進行にあたり、タイムキーパー = タイマー設定を行ってくれる人を募集します。
「やっても良いよ」という方は、このコメントにリアクションをしてください :pray:
リアクションしていただけた方からランダムで選択します。

!timer 2

## 読書パート

- 範囲指定は節・項の単位
- 並行して、感想や疑問点をmdに書き込む
- 時間が余ったら範囲を超えて読んでも良いが、感想・疑問点を書き込むのは指定範囲まで

## 投票パート

- 議論したい箇所 → :thinking_face: 
- 議論したいわけではないが、共感した箇所 → :+1:
- 議論したい箇所を優先してピックアップ
- 共感した箇所は、議論したい箇所が終わったら、「特に話したいトピック」として提示されればピックアップ
    - 「特に話したいトピック」が提示されなければ、次の節へ
- :+1: は、スルーされる可能性あり. スルーされたくないテーマは :thinking_face: をつける

## トークパート
### :thinking_face: パート

- :thinking_face: 付きのコメントを優先
- :+1: は、「これを話したい」という指定が有れば話す
- :okawari: を投票した時、その後のトークを促進する意味から、理由を書けるとなお良い
  - 必須**ではない**。書けなくても/書かなくてもOK。「よくわからなくてモヤモヤするぐらいしか理由が書けない」という場合など。
  - 理由を書く場合も、**事後でOK**。投票してから理由を書き始める、でもOK

### :+1: パート
特に話したいトピックがあれば、任意のトピックを選択してトーク

### 次回繰越(:eyes:)パート
- :thinking_face: の消化で終了時刻になった or 終了時刻が近い場合
- 次回開始時に取り上げたいトピックについて、 :eyes: で印を付ける
- :eyes: 付きのトピックがあれば、次回開始時にそのトピックからスタート
- :eyes: 付きのトピックが無ければ、通常通り次の節からスタート

### タイマー
トーク時間

!timer 10

:+1: 選択時間

!timer 2

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

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

# 読書メモ

## 2.3 変更を歓迎するコードを書く > データではなく、振る舞いに依存する p.45~51

### discord開始地点

- https://discord.com/channels/432531367427964929/898843794101911622/936865645772038144

### 感想

- Rubyの知識なくて頭に入ってくるまで時間がかかる :joy:
- cog をメソッド経由にしてフィールドは必ず参照しないというスタイル、Rubyだと attr_reader のおかげで行いやすいけど、PHPとかだと少々面倒
- なので、最初は割と構わずフィールド変数直接参照して、必要になったらあとからメソッドでラップ、というのが実際には個人的に多い
- Scalaのように引数無しだとメソッド呼び出しの `()` を省略できる言語だったり、typescriptのようにプロパティ構文がある言語 = メソッドコール/プロパティ参照とフィールド参照の形を同じにできる言語だと、ここで言われている「フィールドを参照している箇所を全部変更」なんて手間も生じなくて、素敵

> どれだけ問題ばかりに考えが及んでしまったとしても、みなさんは自身からデータを隠すべき です。 - p.48

- ここで言う「データ」は、もっぱら「実装の詳細」の類義語的な表現として使われていそう
- [→トークパート](https://discord.com/channels/432531367427964929/898843794101911622/936883303905128498)
- 「データ = 実装の詳細 ∋ フィールド変数」へ直接依存するのではなく、メッセージ（ここでは、ほとんどメソッドコールと同義）を経由せよ、という感じなのだろう:+1::+1::+1::+1:
- 直後で `インスタンス変数に結びついていることがよくないのであれば、複雑なデータ構造への依存はさらによくありません。` とも書いてるし、インスタンス変数は「データ」に含まれるよう類のものである、というのがここでの前提っぽい
- 自身が知っている情報すらも、メッセージを経由して参照せよ、直接依存するな、という発想

- 「データ」に依存させるな。という文言だけだと「じゃあどうやってクラス作るのよ？」って思うけど、アクセサーメソッドもしくは、計算した結果を返すメソッドにする。
- C#で昔書いていたときには、get;set;をそのクラス内でのメソッドでも使うのはあまりピンと来てなかったけど、一律振る舞いに依存させるようにしておけば、そこまで酷いコードにならないようにはなるかな :+1:
- プロパティ記法のある言語なら、後追いでプロパティ化しても影響が出ないようにできたりもするので、Rubyより懸念は減るかも

- イニシャライザではデータを渡して振る舞いを渡すな、外部には振る舞いを見せてデータを見せるな、と理解した
- [→トークパート](https://discord.com/channels/432531367427964929/898843794101911622/936886420340092958)
- あるデータからふるまいとしてis〜〜というものが導かれるときに、コンストラクタの引数の時点でis〜〜を渡す形だと、インスタンスの作り手側が判断してて知識もれてるなーという意図でした

> 何か有用なことをするためには、dataメッセージの送り手それぞれが、何のデータが配列のどのインデックスにあるかを完全に知ってなければなりません。

- これ、他の人が書いたコードがこうなってるとすっごくイラッとしてわかるか！！って気持ちになるけど、気を抜くとたまに自分でも踏み抜くなー
- 複数ある引数がどれも同じプリミティブ型、とかも部分的にこれにあたる可能性あるなあ、言語によるけど。
- 既にこれと同じことをやらかしてるから改善しないといけないと思った。

> ObscuringReferencesは、初期化時の引数を@data変数に保管します。 - p.49

- こうした「複雑なデータ構造」を使おうとしたときに、最終的にオブジェクトするにせよしないにせよ、「複雑だから、これを専門に取り扱うオブジェクトを用意しよう」という発想に行けるかが、（本書で言うところの）OODおよびOOP的なスタイルに慣れ親しんでいるかの一つの基準点になりそう:thinking_face: :thinking_face:
- [→トークパート](https://discord.com/channels/432531367427964929/898843794101911622/936874135521464322)
- どうやったらその発想にいけるかな？ :thinking_face: :thinking_face:

>　複雑な構造への直接の参照は混乱を招きます。データが本当はどんなものかをわかりにくくす るからです。また、メンテナンスも悪夢のようです。配列の構造が変われば、参照しているところ をすべて変更する必要があります。 p.50

- PHPで、ありとあらゆるところで array が駆使されているコードとか、配列とハッシュが入り乱れて控えめに言って地獄（実体験）:innocent:
- Perl への挑戦状ですね、わかります :)

### 疑問

# 次回実施
## 予定
2022/02/05 Sat 15:00〜17:00

## 再開地点
あらゆる箇所を単一責任にする > メソッドから余計な責任を抽出する(p.51~54)

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

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

* 欲張りすぎず、時間内で終わった!
* 今回は、読書の範囲をちょっと広く取りすぎてしまった
* 節や項に引っ張られず、分量ベースで判断した方が良さげ :+1:
* 意外と、マークがついてないところも話してみると疑問点があったり、議論盛り上がったりする余地があった。
* 意外と無意識に見逃しているわからないところがあるからそれも理由かな
* そもそも、全部の感想を読めていないからマーク付けの手が回っていないこともしばしば
* 各パートや各議題へ移る間があるので、いまどういう時間なのか、わからない時があった :+1:
* :goti: のあとも結構盛り上がる。アディショナルタイムタイマーつけていくのは効果ある？
* 自分は途中参加したので、その時のうまい入り方が気になるかな
* 今はどういう時間なのかが、パッとひと目でわかるといいかもしれない
* ほぼ毎回遅刻してる身としては、ちょっとチャットを遡るとわかるのであまり苦労しない。(慣れているからか)
* この問題を解決する機能を実装しときます。:+1:
* 『感想を書く』パートです、というコメントをチャットに書くなど
* [こういうの](https://discord.com/channels/432531367427964929/898843794101911622/936883059238793266)では足りてない?
* ピン止めしたりすると、少し改善したりする?
* 権限無いとピン止めできない気が
* [このへんから参加したから気づかなかった](https://discord.com/channels/432531367427964929/898843794101911622/936869680294006825)

### 疑問点

- イニシャライザの振る舞いを渡す？　ところの意図
- > イニシャライザではデータを渡して振る舞いを渡すな、外部には振る舞いを見せてデータを見せるな、と理解した
- https://discord.com/channels/432531367427964929/898843794101911622/936886420340092958

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

## 次回の課題

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