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

# 開催概要

* 日程: 2022/12/03 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.5_コンポジションと継承の選択_コンポジションの影響を認める_まとめ_p.232_p.236
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1048572014279004232

### 感想

> コンポーズされたオブジェクトは、多くのパーツに依存します。それぞれの部品は小さく、かんたんに理解できるものであったとしても、組み合わせられた全体の動作は、理解しやすいとはいえないでしょう。個々の部品はすべて「見通しが良い」ものであったとしても、全体はそうでないかもしれません。 - p.233

- 一つ一つのモジュールが単純だったとして、それらを組み合わせたモジュールが引き続き単純である保証は無い. 「全体 > 部分の総和」というアレ（FYI. ホーリズム） :+1:
- 部分を組み合わせる側にもバリエーションがあり、しかし基本的な構造は一致しているような場合には、コンポジション"する"側で継承が有効に働く可能性もある
- ex. コンポジションした結果の使い方は概ね一致するが、コンポジションするオブジェクトの内訳と、一部に利用方法に若干の差異がある → 同一部分を継承やモジュールで共有し、そうでない部分は個別のクラスで実装する
- 自転車の例と同じく、コンポジションで置き換えることもできなくは無いが、それによって個別の振る舞いを片っ端から委譲する羽目になるのであれば継承する方がよっぽどスマート.

> p.232: アプリケーションのコス トを下げるための秘訣は、それぞれのテクニックを正しい問題に適用することでしょう。

- だいじ。

> p.234: 継承が最も適しているのは、過去のコードの大部分を使いつつ、新たなコードの追加が比較的 少量のときに、既存のクラスに機能を追加する場合です(Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software

- 改めて読むと、実装の再利用としての意図しかないように読める、悩ましい/やや古くささを感じる説明だ :+1:
- 概念的同一性/類似性を抜きにして語ると、歪な継承関係を発生させてしまうので注意したいアレ :+1:

> p.235: has-a 関係にコンポジションを使う
> p.236: この is-a と has-a の違いが、継承とコンポジションの選択を決断する際の核心になります

- has-a 関係に継承を使ったりすることはないので、本節の主題である「振る舞いの共有」と直接的な関係がなく、急に出てきた感。
- 対比されるのは、is-a/has-aという関係の定義においてであって、この文脈での使い分けでの話ではない。
- 読み取れないだけで、継承やダックタイピングとの使い分けに、何か関係することが書かれている?(深読み)

> p.234: is-a 関係に継承を使う
> p.235: behaves-like-a 関係にダックタイプを使う
> p.235: has-a 関係にコンポジションを使う

- is-aに継承、has-aにコンポジション（集約）を、というのはあちこちで言われる話だが、そこへさらに behaves-like-a という整理を持ち出してきているのはあまり見ない. そして有効な整理という印象.
- 「Xの一種」とまで主張したいわけではない（いわゆる「分類」の一つ、系統樹の一部として整理したいわけではない）けれど、「Xのように振る舞ってほしい」というケースは実際ある.
- is-a/has-a の対比だと、これもis-aの範囲に取り込まれてしまうが、これにbehaves-like-aという名前を与えて区別を与えている :+1: :+1:
- 例えば「抽象クラスを使うか、(mixin|trait|Interfaceのデフォルト実装)を使うか」といったシーンで、is-aとbehaves-like-aの区別を判断に利用できそう

### 疑問
> 振る舞いが、それを構成するパーツの総和を上回るのなら、コンポジションを使いましょう - p.233

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1048583138093318146)
- 今ひとつ言わんとすることがつかめない...「構成するパーツ」がコンポジション"される"オブジェクト群を指すとして、「振る舞いが...パーツの総和を上回る」というのはどういう状態を指すのか :thinking_face:
- 例えば、コンポジション"される"オブジェクトがそれぞれ1つ以上の振る舞いを持つ = 「パーツの総和を上回る」？
- コンポジション"する"側のオブジェクトが、2通り以上の仕方でパーツを使う場合、「振る舞いが...パーツの総和を上回る」ということにはなるのか？
- ここで言う「振る舞い」が誰のものを指すのか不明瞭、というのが一点. 「総和を上回る」という時にその「総和」はどうやって計算されるのかがもう一点.
- 多分、ちゃんと理解しようとしたら引用元読まないとだめ.
- 多分これかな
- https://learning.oreilly.com/library/view/object-oriented-analysis-and/9780201895513/
- とりあえず著者には、「引用する時は引用箇所も明示しなくてはいけません」という文を1000回ぐらい書き取りしてもらおう
- > p.235: 自転車は、そのパーツの振る舞いだけでなく、そこに追加の 振る舞いと、そのパーツの振る舞いとは独立した振る舞いを持ちます。
- のように、「追加の振る舞い……(略)」とあるところからすると、「それを構成するパーツの総和」は「それを構成するパーツの振る舞いの総和」が本来の意味か。
- だとして、そうでないような場合がそもそも存在するのか。 :point_left:

## 9_費用対効果の高いテストを設計する_9.1_意図を持ったテスト_p.237-238
「テストの意図を知る」の手前まで

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

### 感想

> リファクタリングのスキルに乏しい場合は、向上させましょう。継続的なリファクタリングの必要性は、良い設計が自然ともたらすものです。 - p.238

- 若手が勝手を覚えるのにちょうど良さそうなリファクタ場所ないかと、以前探していたチームメイトがいたのを思い出した。

> 変更可能なコードを書くという技巧には、価値の高いテストを書く能力が求められます。 - p.238

- つよつよエンジニアの人が「テストを書かなくても、頭の中にあるテストが動いてる」って話が以前あった。整頓されたテスト可能なコードを書く技術っていうのが確かにあるのだろうなぁ。
- 最近内部実装に手を入れたモジュールで、テストはあるけれど割と大事なポイントが十分にテストされていない、というケースにぶち当たって今ちょっと手こずっている
- なお犯人は「過去の自分」だった模様... :aruaru:

### 疑問
> 下手に設計されたコードは、必然的に変更が難しくなります。実践的な立場から見ると、変更可能性こそが設計時に唯一問題となる指標です。つまり、変更が容易なコードは適切に設計されていると言えます。 - p.237

- またちょっと怪しいニオイのする一文 :thinking_face:
- 「変更可能性こそが設計時に唯一問題となる指標」となるような「実践的な立場」って、どういう立場？
- ややもすると「コードにしか興味がないプログラマ」というスタンスを正当化することにも繋がりかねない、危険な一文な気がする :point_left:
- 著者にそうした意図が無ければ、「実践的な立場」なんてふわっとした言葉に留めないか、重要でない話ならそもそもこの一文書かない方が良いのでは
- 「下手に設計されたコードは、必然的に変更が難しくなります」は真だと思うけれど、その対偶っぽい「変更が容易なコードは適切に設計されている」ではnot(下手)がなぜか「適切」になってる
- 原文も見た方が良さげ
- 訳の問題？
- > Poorly designed code is naturally difficult to change.(...) code that’s easy to change is well-designed.
- ただ、well-designed（上手に設計された）だとしても、「上手」に「適切な」まで含めるのかどうか、また含めるならそれを明示せずふんわりとした言葉遣いに埋め込んでいるという問題は別に消えない.
- 「下手に設計されたコードは、必然的に変更が難しい」 <=> 「変更が容易なら、上手に設計されている」ではなく？
- 上手に設計されているからといって、それは「適切な設計」と一致する保証なんてないのでは
- ex. オーバーエンジニアリング
- 「下手」に「技術的に程度が低い」というだけでなく「適切な設計が選択されていない」も含まれているのだ、と主張すればまあ成立するかもしれないけれど、これはこれで多義語の誤謬を利用しているニオイがする
- 変更容易は大事だとは思いつつ、「唯一問題」までいうのすごい言い切り。 :point_left: :point_left:

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

### 感想

### 疑問

---

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

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

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

- ラスト30分だけ参加でしたが、最終章の序文でここだけでも出た甲斐はあった。(とはいえ、だんだん疑心暗鬼感が出てるという ^^;) :sorena: :wakaru: :handshake:
- 基本的に論理が怪しい人っぽいので、「A -> B」を言い換える表現が出てきたら、とりあえず疑ってかかった方が良さげ（そして、大体何かしらミスっている(^^;） :desuyone:
- 「そもそも大体の人は怪しいだろ」と言われたら、それはs（途中でページが破れて読めない）
- is-a と behavies-like-a を区別して、それぞれについての考え方が提示されている箇所は良い整理だった
- ちょいちょい、こういう「良い」としっかり言いたくなる箇所もあるのが、この本の扱いを難しくする...
- ロールであるという関連の表現で "behave as" というのは目にしたことあったきがする

### 疑問点

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

## 次回の課題
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)

# 次回