凝集度と責務

Editor's Notes

• #5: って思ってました。
• #6: 原点はコードの二重化ではなく、知識の二重化を話している。
• #7: 普段書かないから例が出てこないので絞り出しました。 いや、まあね。フルネームの表現は抽象的に考えてたら空白区切りの文字列ですから（ゴミ） UtilやConstantsほど身の危険を感じるobjectもなかなかない。※自分がレビュワーなら即rejectする。 ここまでひどいコードはなかなかないかもしれないが、多分UtilとかConstantsがあるやつは似たようなコードが絶対あると思う。 多分、古いJavaとかの時代だと結構前処理が面倒だったりして使い所あったのだろうけど（知らんけど、それでも、自分ならなるたけ書かないかなぁ。）、Scalaの場合はそんな面倒なコードに（ちゃんと書けば）ならないのでまず要らない。 大体そういう状況はクラス設計が適切じゃないから同じ知識がUtilとなって散在してしまっていることがほとんどだと思う。
• #8: まあ一番感じたのは、リクエストとレスポンスのモデル複数箇所で使ってしまっていたときでしたね。 いやまあ、これは共通化できているとは言えないのだけれど。 UtilとかConstantsがあるとき大体クソ。
• #9: とか
• #13: 関数の引数にフラグを書くのはフラグ引数っていう有名なアンンチパターンですね。 詳細Clean Codeの「においと経験則」を参照
• #15: そもそもデータクラスと機能クラスに分ける設計は「クラス」本来の使い方ではない。 むしろJavaが言語の仕組みとしてクラスを採用した意図とは正反対の使い方 クラスはデータとロジックを一つのプログラミング単位にまとめる仕組み データをインスタンス変数として持ち、そのインスタンス変数を使った判断/加工/計算のロジックをメソッドに書くのが、クラス本来の使い方。
• #16: インスタンス変数があって、そしてメソッドがある。 振る舞いを表現している。 これは簡単な例だからそりゃそうだろって思うかもしれないけど、実際のプロダクトレベルだとできてないコードは非常に多い。
• #17: 先ほどの例のような設計にしないための視点を紹介します。
• #18: なんとなき、手続的な設計が良くないことは伝わったと思います。 ただ、(僕の例がアレなこともあって)伝わり切ってない気がしますので、いい設計にするために必要な2つの視点を紹介します。
• #19: 凝集度はアプリケーション設計の勉強をしていると必ず出てきてかつなかなか説明が見つからない概念です。そしてすごく重要。
• #20: 参考 https://qiita.com/j5ik2o/items/a64007c6d7a89ec2e086 もう中古でしか手に入らない感じだけど、オブジェクトデザインって本に責務の定義は書いてある。
• #21: DDDコミュニティを主宰しているログラスの松岡さんの定期ツイートが分かりやすいので紹介します。
• #24: 水洗トイレを想像しながら最低限の仕様を考えました。
• #25: 機能に着目するとこのような実装になる。 さっきのStringUtilのような実装ですね。 利用者は水洗トイレだと思って使おうとするが、用を足すための穴は空いておらず、流し方もわからない。 まさか、自分で一旦床(メモリ上)に糞を出し、トイレと書かれた箱に入っている壺にそれを入れて、流すにはトイレ箱を川に持っていって流さなければならないとは思わないだろう。
• #26: 本を積んで保管するのはトイレの責務ではありません。
• #27: トイレが水や糞尿を保持するタンクを持ち、トイレに対して糞尿をすることができ、流すことができる。 そのオブジェクトが何をするのかを表現する必要がある。
• #28: それぞれの詳細については記載の書籍に書かれています。 増田さん本の内容やイベントで話ている印象だと、こういったアプリケーション設計を現場に浸透させるには極端さが必要だと思っている節があります。 自分もそっち派で、やはり緩いコードレビューでは浸透しないですし、まずは大袈裟に極端にやって、そこから段々と自然体になっていくものだと思ってます。
• #29: やりがちがだけど
• #31: http://xerial.org/scala-cookbook/recipes/2012/06/29/enumeration DNAとか生物的なものがあってるかは知りません。
• #33: これは例割愛します。