Download to read offline
凝集度と責務
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16. 手続的設計からオブジェクト指向へ ● データをロジックを分ける実装では距離が離れすぎてどこで何をしているかの見通しがつかな くなる。 ● 機能・操作に着目すると手続的になりがち。 ●DRY原則は処理をまとめる共通化のことではない。知識をシステム内で単一にしろという話。 ● オブジェクトに注目することでDRY原則を満たせるようになる。
- 17.
- 18.
- 19. 責務 責務は、ソフトウェアオブジェクトについて大ざっぱに記述したものです。責務には、以下の3つの 主要な項目が含まれます。 ● オブジェクトが行う動作 ● オブジェクトが持つ知識 ●オブジェクトが他に影響を与える主要な判断 （オブジェクトデザイン 4.1 責務とは何か）
- 22.
- 23.
- 24.
- 25.
- 26.
- 27. オブジェクト指向らしい設計にするには ● メソッドをロジックの置き場所にする ● ロジックを、データを持つクラスに移動する ●使う側のクラスにロジックを書き始めたら、設計を見直す ● メソッドを短くして、ロジックの移動をやりやすくする ● メソッドでは必ずインスタンス変数を使う ● クラスが肥大化したら小さく分ける ● パッケージを使ってクラスを整理する 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 増田 亨
- 28. 危険な臭い やりがちで、低凝集、責務不明瞭を引き 起こす具体例 ● 定数クラス ● Common,Utilクラス 低凝集、責務不明瞭の兆候
- 29.
- 30.
- 31. sealed trait, sealedabstract class を使って、 固定パターンは表現します。 コードなどの対応がある場合は、ファクト リを準備して生成できるようにしておくと 良いです。 ファクトリはテストが必要です。 これならば、DNAにはどのようなパター ンがあって、それぞれどういう特徴、仕様 を持つのかさらに追加で記述することも可 能です。 どうすべきか？
- 32.
- 33. まとめ ● 手続的な設計ではなく、オブジェクト指向に ● データクラスと機能クラスに分けてはいけない ●いい設計のポイントは凝集度と責務を常に考えること ● 定数クラスやUtilを使わない。おくべき場所が他にあるはず。
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 これは例割愛します。