変更がかんたんなソフトウェアの設計技法 結合度 凝縮度 単一責任 費用対効果の高いテスト

1. オブジェクト指向による
変更容易性の高い
ソフトウェア設計技法
Presenter
Fujii Ryosuke
twitter @fujii_rrr

2. 良いコードとは
● 良いコードは、正しく動作することに加えて「変更がかんたん」である
● 変更がかんたんとは
○ 見通しが良い
■ 変更箇所の特定がかんたんにできる
■ 変更による影響範囲をかんたんに特定できる
○ 合理的である
■ 要件の変更が小さければ、コードの変更も相応して小さい
○ 再利用性
■ 既存のコードはかんたんに 再利用できる

3. 変更がむずかしい例
● あるクラスを少し修正したなのに、他のクラスのテストコードが大量に落ちる
● クラスが1万行あって一体何をしているのか、あるコードを変更した時にどういう影
響がでるのかわからない
● パフォーマンス目的でDBのスキーマを変えるだけなのに、ビジネスロジックやUIロ
ジックも変更しなければならない
● 既存のコードを使うにはコピペするしかない

4. なぜ変更がかんたんである必要があるのか
● システムの最終形である外部仕様が決まっていない
● 変更の要求は絶えず発生する
○ ビジネス要件の追加
○ バグ修正
○ UI改善
○ パフォーマンス改善による DBスキーマ・DBの変更
プロダクトの成長＝事業の成長である我々にとって
「変更がかんたんである」ことが事業成長の鍵を握る

5. 単一責任にクラスを分割する
● 人間は複雑で大きな問題をそのまま解決することはできない
○ 様々な関心ごとが絡み合い複雑で大きな問題となる
■ レイアウトしたい
■ 業務ロジックを組み立てたい
■ データを加工したい
■ 計算したい
■ 通信したい
■ 永続化したい
● 関心の分離
○ 解決すべき複雑で大きな問題を単純で小さな問題に分解する
○ 単純で小さな問題を個別に解決する＝部品（モジュール）
○ 部品（モジュール）を組み合わせて、複雑で大きな問題を解決する。

6. 単一責任にクラスを分割する
● 解決すべき問題領域を「責務」「責任」と呼ぶ
● クラスが「単一責任」を持つように設計する
● なぜ「単一責任」にすべきなのか
○ 責任を複数持つ場合、再利用性が低く、壊れやすい
○ １つの目的に関することだけを行う＝高凝縮
利用する側
モジュールA
利用される側
モジュール
問題X
問題Y
利用する
モジュールB

7. 複数責任のクラスを見つける方法
● modeみたいな区分でクラス内の振る舞いを制御している
● インスタンス変数を使用していないメソッドがある
● クラスを一文で説明してみて、「または」が入る場合、複数の責務を持っている可能性がある

8. 依存とは
● モジュールAがBについて「知っている」時
AはBに依存していると言える
● 「知っている」ことが多いほど密結合
● 例
○ OrderControllerクラスは
注文が注文明細を持っていることを知っている
■ 不要な依存と言える
■ 注文金額を計算するために注文 IDさえ
伝えれば良い

9. 吉野家で牛丼を頼むために、調理法を知る必要はない
「牛丼並」を注文する
吉野家
（店員の名前は知らんけど）
吉野家の店員にメニュー名を使えれば注
文できる
顧客
外部から見た時に、
牛丼をどう作るかは
ブラックボックス
注文受付

10. 吉野家で牛丼を頼むために、調理法を知る必要はない
吉野家
まず冷凍された牛肉を６時間自然解凍した後に、、
しょうゆ・みりん・酒・砂糖を入れて１時間煮込んでください。
その後、ほかほかの白ごはんをどんぶり茶碗に盛って、
煮込んだ牛肉をその上にかけてください。
顧客
牛丼をどう作るかという手順を顧客が知っているため、
手順を変更する度に、顧客の注文の仕方を修正しなければならない

11. 疎結合にする技法
● 具象ではなく抽象に依存する
○ 内部詳細を隠蔽する
○ インタフェースに依存する
日本の課税計算クラス
アメリカの課税計算クラス
カナダの課税計算クラス
注文金額クラス
switch (国区分)
case JP:
日本の課税計算クラス
.calcTax
case US:
アメリカの課税計算クラス
.calcTax
case CAN:
カナダの課税計算クラス
.calcTax
calcTax
calcTax
calcTax

12. 疎結合にする技法
● 具象ではなく抽象に依存する
○ 内部詳細を隠蔽する
○ インタフェースに依存する
日本の課税計算クラス
アメリカの課税計算クラス
カナダの課税計算クラス
注文金額クラス
なんからの課税計算をするクラス
.calcTax
何らかの課税計算をするクラス
calcTax

13. 疎結合にする技法
● クリーンアーキテクチャにおけるUseCaseがRepositoryに依存する関係と同じ
RemoteDataSource
LocalDataSource
UseCase
なんからの方法で永続化するクラス
.save
何らか方法で永続化するクラス
save
ビジネスロジックから具体的な永続化の方法を分離する

14. 費用対効果の高いテスト
● テストコードの目的
○ バグを検知することはもちろんだが、
○ テストコードを書かない時に比べて、 開発の生産性を上げること
● テストの種類
○ ユニットテスト
■ モジュールの動作試験
○ 結合テスト
■ サブシステムレベルの動作確認
細かいテストはユニットテストで行う

15. プライベートメソッドはテストすべきか
● 答え＝すべきではない
○ 冗長であるため
■ パブリックメソッドがテスト内で、プライベートもテストされているはずである。プライベートメ
ソッドをテストするのは冗長
○ 変更コストが高い
■ プライベートメソッド＝内部詳細はパブリックメソッドに比べて変わりやすい。
モジュールのインタフェースに対してテストを行う

16. 副作用のあるオブジェクト呼び出しのテスト
● クラス内に副作用のあるオブジェクト呼び出しがある場合、ユニットテストとしてどこまでテストすべき
か
○ 例）
■ 注文作成クラスで通知オブジェクトを呼び出しているが、
ユニットテストとして通知テーブルにレコードが作成されたことまで確認する必要があるのか
○ 個人的には、モックを使って、「オブジェクトの呼び出しが適切に行われたこと」あるいは「戻り値の確認」をテストする
だけで良いと考えている。
■ 理由
● テーブルにレコードを適切に作成することは、通知オブジェクトのユニットテストの範囲であり、アクショ
ン作成クラスのテストではない。
● もしオブジェクトの呼び出し自体に問題があれば、結合テストで検知できる
● 通知オブジェクトの内部処理変更時に、呼び出し側クラスのテストコードまで変更しなければならない。