OOD実践ガイド読書会 - テストプレイ1回目
===
###### tags: `オブジェクト指向設計実践ガイド読書会`

# 想定フロー(8分は適宜調整)
1. 8分で読めそうな範囲を予め定めて、8分間読む
- 範囲に届かなくても、オーバーしても良い
- 並行して、感想や疑問点をmdに書き込む
2. 感想の内、特に話したいトピックを投票(1~2分?)
3. トピックについて話す(5~10分/トピック?)
4. 取り上げたいトピックが
- 残っている → 3. に戻る
- 残っていない
- 1h経過前 → 1.に戻る
- 1h経過 or 1h経過しそう → 終了、次回の予定決め

# 開始地点
https://discord.com/channels/432531367427964929/843490960460480522/891144698973024327

# 2.2 単一の責任を持つクラスをつくる (1杯目)
## 感想

> オブジェクト 指向 設計 の システム の 基礎 は「 メッセージ」 です。

OOPには、メッセージ指向とクラス指向の種類があると聞いたけど、この本ではメッセージ指向と捉えていいのだろうか。
- 根幹のアイディアはメッセージ指向を意識しているけど、実現方法としてクラスを使う、みたいな関係を意識していそう
- 実際、SmalltalkもSmalltalk-76からクラスの仕組みを導入してはいますね(あちらのクラス導入は理念的というよりは、実行処理速度の都合上、という事情がメインですが)

- 自転車ドメインいいぞ
- (コグって言葉、伝わるのか・・・？
- (52-30 は差が大きすぎるのでは
- :eyes: https://fixedstyle.net/parts/cog_lockring/

> 目標 は アプリケーション を モデル 化 する こと です。 クラス を 使い、「 いま すぐ に」 求め られる 動作 を 行い、 かつ「 あと にも」 かん た ん に 変更 できる よう に モデル 化 する の です。
- この本の主張いいかんじ。

> 長き に 渡っ て、 アプリケーション の 変更 を かん た ん に する 性質 を 特定 する ため の 研究 がさ れ て き まし た。
- 最近、アプリケーションの変更容易性や拡張性を最初から追い求めて、変に複雑化しないか心配になってきている。シンプルなものを追求して「それってYAGNIだよ」なんて言うのも、なんだかなぁという気持ちもちょっとある。という本の内容に関してではないけど、ちょっと思ったこと :+1: :+1: :+1:

> p.39
> ドメイン内のオブジェクトを表す名詞を見つけようとしながら読むと、「自 転車」や「ギア」といった単語が目に付きます。これらの名詞は、クラスになる候補のうち最も単 純なものを表します。

- やはりはじまりは名詞さがしから。
- 名詞でも対象にしない、名詞だけど対象にする、への展開あるのかな、と思いながら読んでる。

> 直感的に「自転車」はクラスになるだろうと思いますが、上記のコードでは自転車の振る舞いについて何ひとつ挙げていないので、いまのところ基準を満たしているとは言えません。一方「ギア」にはチェーンリングとコグ、そして比があります。つまりデータと振る舞いがあるのです。ギアはクラスとなるのにふさわしいでしょう。

- 名詞だからといって何でもかんでもクラスにするべきでないという指針、大事:+1::+1::+1:
- 初心者の頃はやらかしがちだった気がする

> p.40
> しかし今回のような単純なケース、つまり Gear がオ ブジェクトから継承するというのは、とても基本的なことです。

ここは、「Gear(クラス)がObject(クラス)から継承する」であるべきところを、勢い余って「オブジェクト」って書いちゃった?

> ・利用 性 が 高い（ Usable）： 新しい 環境、 予期 し て い なかっ た 環境 でも 再利用 できる :+1:
- 最近は、この再利用性が高い、というものには疑問というか、他の特性と比べて強く意味を見出していない自分がいる。基本、オブジェクト指向によってなされるのは、いまの自分たちが考えているメンタルモデルを上手く表現することであるので、その結果によって再利用性が高まることはあれど、それは結果でしかない、という感覚を抱く :+1::+1:
- 「結果として」再利用できる　と思っている。
- OO初期は再利用性が喧伝されたけれど、だいぶまえから、再利用性を目的にするのは不適当、という論調だと思う。少なくとも、プロジェクトまたぎでの再利用性は重視しない方がよい、くらいの。

## 疑問

## 全体への感想

* つかれた……(ぉぃ
* ペースが速いので、体力消耗する感はある
* タイマー欲しいかも
* 読んでHackMDに書いているときだと、（チャットに気づかなくて）時間に気づかない時があるかな
* テキストオンリーも、結構進行していきますね。
* 1回目から、徐々に慣れてきた？

# 2.2 単一の責任を持つクラスをつくる (2杯目)

p.40 「図 2.2 に示すとおり、」〜

## 感想

- inch と聞いた瞬間もういやな予感しかしない

> 再利用しているクラスは何をするべきかの整理がついていなく、いくつかの責任が絡み合った状態になっているのですから、変更が起こる理由はいくらでもあるのです。目的の用途とは関係のない理由で変更されることもあるでしょう。そして変更が加わるたびに、そのクラスに依存するクラスをすべて破壊する可能性があります。アプリケーションが予期せず壊れる可能性を高めているのです。多くのことをやりすぎるクラスへ依存するとは、そういうことです。
- 単一責任原則の原典を踏まえた解説 :+1::+1::+1:
- 「多数の責務」を抱え込むとは、原典の説明に乗っ取るなら、「複数の変更理由」を抱え込むということで、だから様々な変更にさらされて、変更理由が整合していないと大変なことになる、というアレ

- Ruby の attr_reader ってメソッド扱いだったのか・・・
- Rubyのキーワードっぽいのはだいたいメソッド
- puts とかもメソッド
- public とか private とかも

> Gear は「 進化 する」 アプリケーション の 数 ある クラス の うち の、 最初 の 1 つ です。 効率的 に 進化 できる よう、 コード は 変更 が かん た ん な もの で なけれ ば なり ませ ん。
- それなんだよなぁ。効率的に進化をさせるために、変更が簡単でなければならない

- P.42冒頭「上記のバグが導入されたのは・・・・・」
- 利用側のコードが書かれていないからそもそもこれはバグではないと思う。
- 利用コードがあるかないかではなく、どうあるべきかの仕様によって判断されるべきではないかしらん。

> 再利用がかんたんなクラスとは、着脱可能なユニットです。 明確に定義された振る舞いから成り、 周りとの 絡み合いはわずかしか あり ませ ん。 変更 が かん た ん な アプリケーション は、 積み木 が 詰まっ た 箱 の よう な もの です。 :+1:

- あとで説明があるとは思うけど、これはカプセル化の話だよね
- モジュール化、コンポーネント化の話のようにも見える。

## 疑問

## 全体への感想
> - 開始タイミングの同期
> - 再開箇所の同期
> が直近見えてる課題かなあと

# 次回実施
## 予定
10/9 14:00〜

## 再開地点
2.2 単一の責任を持つクラスをつくる」内の「クラスが単一責任かどうかを見極める」

## 今回からの変更点
- 節・項単位で読書範囲を定める
- 時間が余ったら、読書範囲を超えて読んでも良いし、読み返しても良い
- ただし、感想・疑問は指定範囲内に留める
- 読書時間をちょっと伸ばす
- 8→10
- その後、適宜伸ばしていく