# ミノ駆動本_読書py[10] みんなのメモ ###### tags: `ミノ駆動本` - このメモはWebに公開されています（HackMDチーム） - リンクを知っている人は見られます - HackMDにログインして編集できます ## お願い事項 https://twitter.com/MinoDriven/status/1541334416622256130 > 【お願い】 拙著『良いコード／悪いコードで学ぶ設計入門』に関する情報発信について。 ブログ等で発信の際は、引用の範囲を超え、著作権侵害となる場合は勿論のこと、 拙著の詳細内容が分かるような表現での公開はお控え頂けると助かります。 ご感想や拙著に基づく試行錯誤は歓迎です。 #ミノ駆動本 とミノ駆動さんが仰られていますので、勉強会そのものでも詳細内容がわかる記述はしないように気をつけていきましょう。 ## このメモについて このメモは ミノ駆動本_読書py[10] のメモです https://pythonista-books.connpass.com/event/266398/ 読む範囲: 6章 ミノ駆動本のサポートページより、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:でお願いします * 票数が多い話題から話していきます。 ### 6 条件分岐 ―迷宮化した分岐処理を解きほぐす技法― #### 6.1 条件分岐のネストによる可読性低下 - 早期return！『リーダブルコード』でも見た早期returnじゃないか！ - - #### (6.2 switch文の重複 は範囲外) - [ミノ駆動本_読書py[2]](https://hackmd.io/qwWRR8lSSlqkiKdo-XLNJg)で取り上げました - **今回は6.2は範囲外です**（クソコード動画「switch文」も範囲外です） - （_取り上げなくていいです_）Pythonだと定義した関数を引数に渡せるから、共通のシグネチャを持つ関数群を使えばストラテジーパターンができるかも #### 6.3 条件分岐の重複とネスト - （前提条件をわからずに）最後のサンプルコードだけみると間違って継承を使っちゃいそうな気もしてきた・・・ - ポリシーパターンによる条件の部品化、いいなあ - 部品化しているから再利用できる！ - huggingface/tokenizersの実装もポリシーパターンっぽいところがあるなあ - 例 https://huggingface.co/docs/tokenizers/api/normalizers - 文字列の前処理（小文字にする・Unicode正規化するなどなどを全部部品にしてユーザが組み合わせられるようにしている） - ポリシーパターンってデザインパターンではないんですね（ストラテジーパターンはデザインパターン）。どこから来たんだろう？（初出の文献にあたりたい） - >「Strategy」（別名：Policy） パターン - https://liginc.co.jp/web/programming/php/136131 - おんなじものなのか？ - エヴァンス本で同じものとして書かれているっぽい！ - https://qiita.com/magicant/items/2846840f749059f00cf3 - #### 6.4 型チェックで分岐しないこと - interfaceを使って分岐を削減しようとしてるのに型チェックによる分岐を追加してはならぬということですね - PythonはUnion型の引数をisinstanceで型チェックして処理することがよくあるので喧嘩別れになるかと思いました - クラス独自の型を引数？で渡すことって出来なかったでしたっけ？（やったことがないから単純にわかっていない） - リスコフの置換原則、むずかしい - なるほど、instanceofで型判定する実装のためにinterfaceと継承型を置換できなくなっている（本文）し、置換できないためにinstanceofを使った実装になっている（注6）と - hotelRates.fee() の意味ェ...... - あー、ここはなんか間違えて罠に陥りそう・・・ - #### 6.5 interfaceの使いこなしが中級者への第一歩 - はい！ - 今、interface設計考えてるけど、本当に必要なのか怪しくなってきたなぁ…… - #### 6.6 フラグ引数 - フラグ引数あかんは『Clean Code』でも説かれていた記憶 - フラグ1つ追加するのは簡単だからやっちゃうんですよね - ミノ駆動本を読まないと罠に気がつけないなぁと改めて思い知らされながら読んでいます - Effective Pythonを読むとフラグ引数を使う前提でこうするといいよというプラクティスが書かれていたりします - （フラグ引数はキーワード専用引数にするといいみたいな主張だった覚え） - すごいフラグ引数の例です：https://github.com/pycaret/pycaret/blob/master/pycaret/classification/oop.py#L115-L193 - 微妙に書けそうでPythonで書けなさそう（これは自分の理解がまだ及んでいないの意です） - ちょっと関係ないかもだけどこの辺りが役に立ちそうな気がしている - https://python-dependency-injector.ets-labs.org/introduction/di_in_python.html - https://speakerdeck.com/shimakaze_soft/python-de-dependency-injection-di-woyaruniha - 何となくリスト6.65で処理が切り替えられそうな気はしてきたけど、、、 あ、こうしたら引数の使わずにいけるよ、か。どっちみち絶対にifを無くすのは出来ないから、ifの中でこれらを呼び出して条件分岐させるイメージ・・・で良いのかな。 - 今の現場、習慣としてフラグ変数書きがち（C言語時代の悪習 - でも、なにかのステータスをきっかけにして物理ダメージと魔法ダメージをわけるのだから、どこかでフラグ管理（的なもの）は必要になるのでは？？ - に対する答えが、EnumとMapなのがイマイチ飲みこない - 永続化されたデータとの関連がチラつく - 永続化されたデータについては、今意識するべき話ではない -