社内向けに凝集度と責務について発表した資料です。

1. 凝集度と責務
トイレのレバーが遠すぎて流すことができません

2. 今回のテキスト
keywords
DDD, オブジェクト指向

3. プログラムを初めて勉強したとき
「同じ処理は共通化することで、効率化を測るのがいいプログラムである」
みたいなことを勉強する

4. DRY（Don’t Repeat Yourself）原則（っぽい何か）
同じコードを書くな！
処理を共通化して、ロジックを１箇所に！
それで修正するときは1箇所の修正で済むのだ！

5. DRY原則（本物）
すべての知識はシステム内において、単一、かつ明確な、そして
信頼できる表現になっていなければならない。
（達人プログラマ 第2章 7 二重化の過ち）

6. 完全に理解した
フルネームってつまり、間に空白がある文字列。よし、共通化だ！
※普段もうこんなコード書かないので頑張って絞り出した
共通機能ライブラリ
方式(CommonとかUtil
とか)

7. 共通化が保守性を下げている。。？
middleNameも追加で。
えっ。。

8. おかしい。。共通化した箇所、修正のたびに影
響範囲は広くて修正しづらい。
てか、この関数何用の関数なんだ？
邪魔だなこの関数。

9. 何がおかしかったのか？

10. 「データクラス」と「機能クラス」に別れた
手続き型の設計になってしまっていた

11. 手続的設計でおこる
ダメな共通化
共通機能ライブラリ
● 汎用的な共通関数
● 用途ごとに細分化した共
通関数

12. 汎用的な共通関数
手続的設計でおこるダメな共通化1

13. 用途ごとに細分化し
た共通関数
手続的設計で起こるダメな共通化2

14. クラスはデータとロジ
ックを一緒に扱うため
の機能
オブジェクト指向をやろう

15. 本来あって欲しかった姿

16. 手続的設計からオブジェクト指向へ
● データをロジックを分ける実装では距離が離れすぎてどこで何をしているかの見通しがつかな
くなる。
● 機能・操作に着目すると手続的になりがち。
● DRY原則は処理をまとめる共通化のことではない。知識をシステム内で単一にしろという話。
● オブジェクトに注目することでDRY原則を満たせるようになる。

17. いい設計をするため
に必要な2つの視点
● 凝集度
● 責務
オブジェクト指向らしく設計する
ために

18. 凝集度
関連性の高いデータとロジックだけを集めたクラスを凝集度が高いと言う。

19. 責務
責務は、ソフトウェアオブジェクトについて大ざっぱに記述したものです。責務には、以下の3つの
主要な項目が含まれます。
● オブジェクトが行う動作
● オブジェクトが持つ知識
● オブジェクトが他に影響を与える主要な判断
（オブジェクトデザイン 4.1 責務とは何か）

22. 「トイレ」クラスの例
低凝集な実装とは、トイレで用を足して、流そうとしたら流すための
レバーが100m先の他人の家のキッチンにあるような状態のこと。
責務が不明瞭とは、炊飯機能付きトイレのようなもの。

23. トイレの仕様
● タンク（便器で水を貼っているところ）を持つ
● 流すことができる

24. 低凝集なトイレ

25. 責務がおかしいトイレ

26. 高凝集かつ責務が正しいトイレ

27. オブジェクト指向らしい設計にするには
● メソッドをロジックの置き場所にする
● ロジックを、データを持つクラスに移動する
● 使う側のクラスにロジックを書き始めたら、設計を見直す
● メソッドを短くして、ロジックの移動をやりやすくする
● メソッドでは必ずインスタンス変数を使う
● クラスが肥大化したら小さく分ける
● パッケージを使ってクラスを整理する
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 増田 亨

28. 危険な臭い
やりがちで、低凝集、責務不明瞭を引き
起こす具体例
● 定数クラス
● Common, Utilクラス
低凝集、責務不明瞭の兆候

29. 低凝集の代表、定数クラス
固定値のパターンを表現するのに使われる。
定数をまとめて管理しているので、修正が発生しても修正が容易なように見える。
しかし、その定数がどこでどのように振る舞い、なんのための値なのかが結局のところ変数名くらい
しか手がかりがない。
ロジックと値の距離が遠くなりがち

30. よくあるのはやはり右のような例。
DNAの定義として、Adenine, Thymine, Cytosine,
Guanineがありますって言われた時にその対応を
Constantsオブジェクトに書いて、判定でConstantsと
比較してしまう。
DNAの使用表現として浅いし、これ以上何もできない。
Constantsクラスはファットになりがち。
またロジックも各所に出てきちゃうので、DRY的にも
NG

31. sealed trait, sealed abstract class を使って、
固定パターンは表現します。
コードなどの対応がある場合は、ファクト
リを準備して生成できるようにしておくと
良いです。
ファクトリはテストが必要です。
これならば、DNAにはどのようなパター
ンがあって、それぞれどういう特徴、仕様
を持つのかさらに追加で記述することも可
能です。
どうすべきか？

32. 責務不明瞭の代表、Common, Util クラス
この手のクラスが存在する時、どのオブジェクトの振る舞いとして表現すべきかが考えきれていない。
データとそれに対する処理が遠いので、どのクラスで使うのか？なんの値の仕様なのかがわかりにく
く、見通しがつかなくなる。
そもそも気づくことも難しいので、似たような処理が複数箇所で作られかねない。

33. まとめ
● 手続的な設計ではなく、オブジェクト指向に
● データクラスと機能クラスに分けてはいけない
● いい設計のポイントは凝集度と責務を常に考えること
● 定数クラスやUtilを使わない。おくべき場所が他にあるはず。