# ミノ駆動本_読書py[9] みんなのメモ
###### tags: `ミノ駆動本`

- このメモはWebに公開されています（HackMDチーム）
- リンクを知っている人は見られます
- HackMDにログインして編集できます

## お願い事項

https://twitter.com/MinoDriven/status/1541334416622256130

> 【お願い】
拙著『良いコード／悪いコードで学ぶ設計入門』に関する情報発信について。
ブログ等で発信の際は、引用の範囲を超え、著作権侵害となる場合は勿論のこと、
拙著の詳細内容が分かるような表現での公開はお控え頂けると助かります。
ご感想や拙著に基づく試行錯誤は歓迎です。 #ミノ駆動本

とミノ駆動さんが仰られていますので、勉強会そのものでも詳細内容がわかる記述はしないように気をつけていきましょう。

## このメモについて

このメモは ミノ駆動本_読書py[9] のメモです
https://pythonista-books.connpass.com/event/264219/

読む範囲: 8章(8.2)

ミノ駆動本のサポートページより、Javaのサンプルコードが見られます。
https://gihyo.jp/book/2022/978-4-297-12783-1/support

## 読書会の流れ

* 20:00〜20:30 **自由参加**のもくもく会（個人作業）
- 事前に読む時間がとれなかった方はここで読んじゃいましょう（ざっとで大丈夫です）
- 合わせて、この**HackMD**に話したいことを各自書いてください
- ログインすれば書ける設定にしています
- ここがわからん、ここはわかった　お気軽に書き込んでみてください
- HackMDの書き込みに投票し、みんなが気になるところをわいわい読み解いていきます
* 20:30〜22:00 読書会本編（みんなでわいわい）
* Discordでスライド共有して別途案内します
* 20:30開始の本編では、「わたしこれ気になる！」
という話題に `:+1:` と書いて投票します。
* :+1: する上限はありません。
気になる話題に全部 :+1: しちゃいましょう。
ただし1つの話題には1個だけ:+1:でお願いします
* 票数が多い話題から話していきます。

## 8章を通しての感想

- 全体的に「こうしたら良いよね」という点は理解できた気がする
- ミノ駆動さんが言うところの「良い設計」がちょっとずつ分かってきたというか
- 色々な観点から悪魔を挙げてくれていて、理解が深まりつつあると思う
- 一方でそれを実践できるかな？というとまだまだなので精進せねば・・・
-
-

### 8章 8.2 密結合の各種事例と対処方法

参考：前回 8.1 https://hackmd.io/flVfioT8SDykS1Siz2qvag

#### 8.2.1

- 「継承元のクラスは（このプロジェクトでは）メンテナンスしない！」ぐらいの思い切りが必要なんですよね
- 継承したくなる動機って何？ :+1:
- 逆に「継承を使うべきシーン」ってどんな時？ :+1: :+1: :+1:
- [Discord](https://discord.com/channels/980982032375107625/980982361896386670/1040594788002578442)
- 共通ライブラリとして提供されているロジックを弄りたい時に、継承して使いました（ログの出力フォーマットの変更など）
- その結果、「継承してよかった！」「継承したことによるマイナスがあった...」「(今思うと)委譲でもよかったかもなど」あれば知りたいです！
- 継承なので、新しいログクラスとしてシンプルに使えました
- Pythonのpathlibモジュールを最近学んだんですが、PathはPurePathを継承してて、基本的にはPathを使えば良いと学んだ一方でこれって良いパターンなのかな？ってちょっと考えておりました:+1:
- https://docs.python.org/ja/3/library/pathlib.html
- 「Pathを使う人」と「Pathを拡張する人」の2つの立場で考えてみると良いかもしれません。使う側からすれば、ファイルシステムに触るときにOSを気にしなくて良いのは嬉しいと思いますし、PurePathにより別OSの計算をエミュレーション可能なのも良さそうです。Pathを拡張する人からしても、第3のOSが現れたときにも拡張しやすそうに見えます(OS技術に明るくないので怪しいですが、直感的にはシンプルそう)。IOに触れるかどうかで区別されているのは嬉しそう :+1::+1::+1:
- [Disord](https://discord.com/channels/980982032375107625/980982361896386670/1040599331473993789)
- 「委譲より継承」は、常に委譲を選択せよ、という話ではないはずだけど、過剰に継承を避ける人がいるのは気になる:+1::+1:
- 問題なのは、真に継承関係にない見かけの継承関係を、継承という機能で実装してしまうこと:+1:
- これは、DRY で触れられているような、コードの共通化に通じるもの
- 継承という機能は強い強制力があるので使いどころが限られてくるのはたしかだが、それにあった場面で使う分には問題ではない
- 概念的に同一であり、振る舞いも同じであり、ライフサイクルを通じて振る舞い方も変化しない、など、強い概念的類似性が認められる場合に限れば、決して避けるものではない
- 通常攻撃と2回攻撃の例、スーパークラスにしようとしていたものを委譲することで、スーパークラスの変更に強くなる（メモメモ
- どちらかというと、メソッドの仕様定義が曖昧であり、暗黙のうちに仕様を変更してしまったことが問題な気がする
- 果たして、 `PhysicalAttack` と `FighterPhysicalAttack` は継承関係にあるのか。どちらも、抽象クラス下の兄弟関係にあるのが扱いやすいのではないか。

	abstract(?) class PhysicalAttak // or interface
	class StandardPhysicalAtack extends PysicalAttack
	class FighterPhysicalAttack extends PysicalAttack

- もしくは、一般的に計算ロジックはこのような分類の階層とは一致しないより複雑な計算式になるので、StrategyパターンやSpecificationパターンなどを使ってクラス階層とは分離して実現すべき :+1:
- 例にされている「攻撃力」は一見単純に思ってしまいがちだが、類似した性質の「割引」についてはよりそうした性質が明らかになりやすい (この不一致から来る歪みが問題を生じやすい)

#### Column クソコード動画「継承」

https://twitter.com/minodriven/status/1353251239237095430:+1:

- やっちゃ駄目なのは分かったけど、これって実際にこういうソースで被害を被った人がいるってことですよねぇ・・・（実装される前にSTOP入らんかったんかなぁと思いつつ、入らんからそうなるんだよね、という結論）
- 「個人情報が漏れたああああ！！！！」は草生える

#### 8.2.2

- Pythonの話じゃ無いけど、「あぁそうしていくべきですよね」っていうのは本を読んでいくうちに理解できてきた気がする！ :+1::+1:
- [Discord](https://discord.com/channels/980982032375107625/980982361896386670/1040604776678825984)
- その理解、kwsk!!!
- 図8.10 のように、クラスの分割基準として、インスタンス変数群とメソッド群の二部グラフを脳内で考えて、密な部分を疎な部分で分割する、ということはよくやる。
- 図8.12 のようなものもこれに包含されるので、こっちのはあまり考えない

#### 8.2.3

- Pythonの可視性は、全部public！（privateを設けていない言語）。8.2.3の内容は使えなさそう。密結合になりえるけれど、どうしたものか
- [Disord](https://discord.com/channels/980982032375107625/980982361896386670/1040605669792940102)
- >プライベート属性よりパブリックな属性が好ましい（『[Effective Python 第2版](https://www.oreilly.co.jp/books/9784873119175/)』）:+1::+1:
- この章（節？）、特にミノ駆動さんの気持ちが籠っている気がする
-

#### 8.2.4

- 「よっしゃ、Pythonにprivateメソッドはないから、ここの悪魔は絶対引き寄せないぞ！Pythonしか勝たん」（←publicでも大量のメソッド持ったクラスは単一責任でないかも）
-

#### 8.2.5

- SellingCommissionクラスのコンストラクタにSellingPriceクラスのインスタンスを渡す実装、知られてよかったなー
- これまでの私は渡したSellingPriceインスタンス自体をSellingCommissionインスタンスにもたせる方法しか知らなかった
- SellingPriceの持っているintの値を取り出してSellingCommissionに設定すればいいというのが学び
-
-

#### 8.2.6

- > 表示関連のクラスの中に、表示以外の責務のロジックが実装されている構造をスマートUI（利口なUIと呼びます。）
- > 良いコード／悪いコードで学ぶ設計入門
―保守しやすい 成長し続けるコードの書き方 仙塲大也　著 初版第1刷発行 P175 より
- 入門書で見かけるコード、けっこうスマートUIな印象。1つの関数でデータを加工してprintまでやる
- 入門書は言語への入門の役割を果たしているのでスマートUIでもいいと思ってますが、設計とか興味出てきたときに「あれってスマートUIだったじゃん！」と気付ける道があるといいのかな:+1:
- 全部が全部最初から完璧に説明しようとするとそれはそれで辛いと思うので気がつける道が欲しいですね
- 「生成」「加工」「出力」あたりは分解の基準としてよく使っています。 :+1:
-

#### 8.2.7

- 巨大データクラス、作りがち
- [Discord](https://discord.com/channels/980982032375107625/980982361896386670/1040608205077762109)
- インスタンス変数たちを束ねたい時はどうすれば。。 :+1::+1:

#### 8.2.8

- 触れられているパターン、初めて聞いたのと注釈でギクッ！！！ってなった:+1:
- 8.1のサンプルコード（ちょっと引っかかった）は悪魔だったとここでわかって、本の構成に脱帽
-

#### 8.2.9

- 神クラス＝大きな泥団子（全然印象違うな）
- 何も考えずにコードを書くと神クラスになりがち
- 設計が足りてない
- どこの設計が担当するんだろう？詳細設計？コード設計？
- 教えて、設計詳しい人（チラッ、チラッ
-

#### 8.2.10

- 『レガシーコード改善ガイド』とてもよい本です。「泣ける技術書」。読書会したい
-