良いコード／悪いコードで学ぶ設計入門 6章のメモ

gihyo.jp

良いコード／悪いコードで学ぶ設計入門 の読書メモです。

長いので章ごとにしてます。

6 条件分岐 ―迷宮化した分岐処理を解きほぐす技法―

• 条件分岐、たしかに複雑になるんですよね…。うまいまとめ方をちゃんと知れそうで楽しみ…。
• もう若くないので、なるべく脳に負担をかけない作りにしておきたいですw

6.1 条件分岐のネストによる可読性低下

リスト6.1

• うーん…生存しているか判定は行動可能判定に入れればよいのでは…。
• 魔法力が残存しているかは、魔法を唱えるメソッドの中に押し込んでしまってもよさそう…。
  • このタイプは指示がそうなってるんでしょうね…。
  • 指示の変更もしたほうがよさそう。

リスト6.2

• 昔見たw
  • Webアプリケーション、初めてだったのでこういうふうに書くもんだと最初誤解しちゃいました…。
• まちがいなくやめたほうがいいと思います！

6.1.1 早期returnでネスト解消

• このテクニックはよく使います！ずっと条件のことを覚えてなくてよいので、頭がラクですから。

リスト6.4

• 生存してなければ早期リターン…。これならたしかに指示への影響はないですね。モヤモヤしますが、元のままというのがとてもいいかも。

6.1.2 見通しを悪くするelse句も早期returnで解決

リスト6.8

• Rubyならcase文が表現力豊かだから、そっちかな。

6.2 switch文の重複

• 仕様の意味がわからん…。魔法の種類から名前を得るってどういう仕様なんだ…？名前は一種のIDだろうに…。
  • ひどい仕様をそのまま実装するとあとで泣くぞ…とも思いますが……。
  • あとから参加して、少しずつ読みやすいコードに変えているのだとしたら、精一杯の行動なのかも…。

6.2.1 即座にswitch文を書いてしまう

• この仕様では……どう直すんだろう……。

6.2.2 同じ条件式のswitch文が複数書かれていく

• この仕様では…………どう直すんだろう…………。

6.2.3 仕様変更時の修正漏れ（case文追加漏れ）

• そりゃそうなるだろ…と思ったら、元のコードにdefaultがない…！絶対に事故るわ……。

6.2.4 爆発的に増殖するswitch文の重複

• コピペすんなや！！！という状況が続いていく……。読んでてツラい……。
  • 納期の迫った開発現場……。

6.2.5 条件分岐を一箇所にまとめる

• まぁわかる……。

リスト6.18

• クラス名変わってるし……。
  • 突然の激変…。
  • こんなに変えて大丈夫か？という気持ちになりました。
• あ…ここではdefaultは入ってる……。

6.2.6 よりスマートにswitch文重複を解消するinterface

• interface、うらやましいなぁ…と思ってます。
  • Rubyではダックタイピング…。そのメソッドがあればいいんでしょ…？的な。
  • モジュールで似たようなこともできるので、必要なときにはやってみます。
• ストラテジパターン…。
• …んーMagicってinterfaceなのかなぁ……。Magicインターフェースを持った魔法以外のものってあるの…？
• ダメだ…サンプルがモヤモヤ過ぎて、頭に入りません><
• コンパイル言語は実装を忘れると叱ってくれるのがいいですよね…！

図 6.4

• やっぱりMagicはインターフェイスじゃなくて、クラスでは……。

Column クソコード動画「switch文」

• …どうもこの「クソコード」という言葉は好きになれません。
  • あとから入ってリファクタリングを担当すると、言いたくなる気持ちはわかりますが……。
  • リファクタリング可能なほどにお金を稼いできたコードだということは忘れないようにしたい……。
• switchがコピーされる話自体は納得です。
  • switch以外にも処理の分岐方法があるということを知らないのが原因、もわかる……。

6.3 条件分岐の重複とネスト

• リスト6.41のコード、なぜ入れ子にしてる……？判定するだけのメソッドなら、ANDでよさそうなのに。
• 優良顧客の判定ロジックをクラス化するのはよさそうです。
  • 判定ロジックの内部までクラスに起こすのは……このサンプルではやりすぎ感が…。
• RubyはArray#all?とかあるからほしいと思わないだけかなぁ…。
• GoldCustomerPolicyやSilverCustomerPolicyのcomplyWithAllはcomplyだけでいいのでは？利用者はAll以外求めてないし…。
• 〜CustomerPolicyのcomplyWithAllは唯一の判定メソッドですが…Customerに関するものなので、Customerを引数にしたほうがよくないでしょうか？将来的に継続年数が条件に入ることもありそうですし。
• 「良いコード」というには、名前がおざなりすぎて…。テクニックとしてはよいと思うんですが、ちょっとなぁ…。
• 最初、「おーよさそう！」って受け入れちゃって、あとから「何じゃこの名前は…」と頭を抱えるタイプ…。

6.4 型チェックで分岐しないこと

• リスト6.54 えええええ？こんなことする？
  • …見かけたんでしょうね……。ツラい……。
• しかし、これもインターフェイスがいいのか…イマイチわかりません…。
  • 部屋代以外に、ルームサービスとか食事代とかにも割増料金があるなら…まぁ、わかるかも。

6.5 interfaceの使いこなしが中級者への第一歩

• まぁ…それはそうだと思います。

6.6 フラグ引数

• リスト 6.60、6.61 ……ひどい、意味がわかりません……。

6.6.1 メソッドを分離する

• 役割を減らすのはもっとも重要かも。
• コードが背景がわからなすぎて、よくなったのかどうか判断できません><

6.6.2 切り替え機構をストラテジパターンで実現する

• それがよかろ…と最初思いましたが、やっぱりコードがよくわからなすぎて、よくなったかどうか判断できません><