Slide 1
Slide 1 text
オブジェクト指向設計原則から
学ぶアプリケーション設計
サポーターズColab勉強会
2018/11/14 @mosmos_21
Slide 2
Slide 2 text
目次
1. はじめに
2. ソフトウェア設計についての概要
3. オブジェクト指向設計原則の5個の原則
4. その他原則に関すること
5. まとめ
1
Slide 3
Slide 3 text
1. はじめに
自己紹介とか
2
Slide 4
Slide 4 text
自己紹介
【氏名】 橋本 尚儒（はしもと たかひと）
【Twitter】 もっさん @mosmos_21
【職業】 ソフトウェアエンジニア(自社製品)
Java/Spring + javascript/AngularJS
【趣味】 競技プログラミング
ビリヤード
3
Slide 5
Slide 5 text
今日話すこと
• SOLID原則の話
• ソフトウェア設計に役立つ原則の紹介
4
Slide 6
Slide 6 text
今日話さないこと
• オブジェクト指向とは何か
• デザインパターンの詳しい話
注意
• コード例はJavaです
5
Slide 7
Slide 7 text
こんな人が対象
6
• 何となくオブジェクト指向分かった気がするけどアプリ
ケーション作れない人
• デザインパターンの勉強をしたけど実際にアプリにうま
く組み込めない人
Slide 8
Slide 8 text
対象じゃない人
7
• オブジェクト指向の本質が理解できている人
• SOLID原則を完全に理解している人
Slide 9
Slide 9 text
2. ソフトウェア設計についての概要
オブジェクト指向 + α の話
8
Slide 10
Slide 10 text
オブジェクト指向についてのおさらい
• オブジェクト同士の相互作用としてシステムのふるまいをとら
える考え方(Wikipediaより)
• 基本的な考え方はオブジェクト同士のメッセージのやり取り
• カプセル化、継承、ポリモーフィズムなどの考え方がある
9
Slide 11
Slide 11 text
オブジェクト指向についてのおさらい
• カプセル化
データのアクセスを直接させない
状態の変更に制約を課すことでオブジェクトの正当性を保証する
• 継承
上位オブジェクトの「ふるまい」を受け継ぐ
• ポリモーフィズム
オブジェクトではなく「ふるまい」そのものに注目して、処理を記
述する
10
Slide 12
Slide 12 text
デザインパターンについてのおさらい
• ソフトウェア設計における設計のノウハウをまとめたもの
（全部で23パターン）
• 生成に関するパターン、構造に関するパターン、ふるまいに関
するパターンに分類することができる
• 再利用性の高い設計がしやすかったり、技術者同士の意思疎通
が取りやすくなったりする
11
Slide 13
Slide 13 text
アプリケーションの設計方針
アプリケーションを作るときにどのように設計しますか?
• オブジェクト指向?
• デザインパターン?
• MVC?3層アーキテクチャ?
その設計、拡張性や保守性は高いですか?
12
Slide 14
Slide 14 text
何とか設計できても…
• ソフトウェア全体を見た時に変更に弱くなっている
• ただ、一部分に関してみるとうまく設計できている
↓
デザインパターンはソフトウェア設計の
どの部分のための設計手法でしょうか?
13
Slide 15
Slide 15 text
3. オブジェクト指向設計原則の
5個の原則について
SOLID原則の話
14
Slide 16
Slide 16 text
SOLID原則とは
1 SRP 単一責任の原則
2 OCP オープン・クローズドの原則
3 LSP リスコフの置換原則
4 ISP インターフェース分離の原則
5 DIP 依存関係逆転の原則
アプリケーションの再利用性、保守性を高くするために必要な設計
の考え方を5個の原則としてまとめた
15
Slide 17
Slide 17 text
SOLID原則に従うことのメリット
16
• 拡張性が向上する
• メンテナンスがしやすくなる
• テストのしやすさ
• 統制された構造を持つため、読みやすく理解のしやすい
Slide 18
Slide 18 text
3.1. 単一責任の原則
Single Responsibility Principle
17
Slide 19
Slide 19 text
単一責任の原則
すべてのオブジェクトはたった一つの
物事に対して責任を持つ必要がある
↓
複数の物事に対して責任を持っていると、
変更に対する柔軟性が保てなくなる
18
Slide 20
Slide 20 text
単一責任の原則
<オブジェクトA>
<オブジェクトB>
責任が複数ある状態とは?
<オブジェクト>
ふるまい1
ふるまい2
ふるまい2の動作が変わると二つのオブジェクトに影響が及ぶ
…
19
Slide 21
Slide 21 text
単一責任の原則
<人事部>
<営業部>
<社員>
労働時間の更新
業務ランクの計算
…
例）社員情報を
管理するシステム
• 人事部で使う業務ランクの計算
方法が変更になる
• 開発者は営業部から利用されて
いることに気づかずふるまいを
変更
営業部が利用している部分の動作
がおかしくなってしまう
↓
20
Slide 22
Slide 22 text
単一責任の原則
責任を単一にする例(抽象クラスと実装に分ける)
<人事部>
<営業部>
<社員:抽象クラス>
労働時間の更新
ランク計算
…
<実装クラスA >
<実装クラスB>
ランク計算
ランク計算
21
Slide 23
Slide 23 text
3.2. オープン・クローズドの原則
Open Closed Principle
22
Slide 24
Slide 24 text
オープン・クローズドの原則
• オープン
拡張が簡単にできる状態にしておく
• クローズド
拡張を行った際に影響範囲が少なくなるようにする
ロジックを追加するときは、
既存のコードをできるだけ改修せずに
新しいコードを簡単に追加できるようにする
↓
23
Slide 25
Slide 25 text
オープン・クローズドの原則
原則が守られていない例(決済サービス)
<決済管理>
支払い
カード払い
モジュール
電子マネー払い
モジュール
モジュールの修正・追加によって
支払いロジックそのものに大きな修正が入る
24
Slide 26
Slide 26 text
オープン・クローズドの原則
解決策: インターフェースに依存させる
• 支払いロジックが実装に依存していない
• モジュールの追加による支払ロジックの修正がない
<決済管理>
支払い
カード払い
モジュール
電子マネー払い
モジュール
<インターフェース>
支払いモジュール
25
Slide 27
Slide 27 text
3.3. リスコフの置換原則
Liskov Substitution Principle
26
Slide 28
Slide 28 text
リスコフの置換原則
27
派生した型は基本型と置換可能でなければならない
↓
置き換えができない
そもそも継承すべきではない
置き換えができる
継承関係が正しいことの指標として見れる
Slide 29
Slide 29 text
リスコフの置換原則
28
<四角形>
違反例
面積取得
Height 設定
Width 設定 <正方形>
class Square
extends Rectangle
Rectangle r = new Square();
r.setHeight(5);
r.setWidth(2);
System.out.println(r.getArea());
これはどのように動作しますか?
Slide 30
Slide 30 text
リスコフの置換原則
29
置き換えができない(= ふるまいが異なる)と何が起こるか
• 利用元で派生先に応じた分岐が必要になる
• オープン・クローズドの原則に反する
置き換えができる状態では、
• ポリモーフィズムのメリットを最大限享受できる
• オブジェクトの処理から関心を話すことができる
Slide 31
Slide 31 text
3.4. インターフェース分離の原則
Interface Segregation Principle
30
Slide 32
Slide 32 text
インターフェース分離の原則
31
上位オブジェクトが利用しない下位オブジェクト
のふるまいへの依存を強制してはならない
下位オブジェクトの無関係なふるまいが
変更されたことによる影響を受けてしまうことがある
インターフェースによって依存を制限する
↓
↓
Slide 33
Slide 33 text
インターフェース分離の原則
32
<下位オブジェクト>
Method – A
Method - B
Method - C
<インターフェース>
Method – A
Method – B
Method – C
上位オブジェクト
上位オブジェクト
上位オブジェクト
実装を分離する (まだ不足)
Slide 34
Slide 34 text
インターフェース分離の原則
33
<下位オブジェクト>
Method – A
Method - B
Method - C
<インターフェース>
Method – A
<インターフェース>
Method – B
<インターフェース>
Method – C
上位オブジェクト
上位オブジェクト
上位オブジェクト
必要なものにだけ依存させる
Slide 35
Slide 35 text
インターフェース分離の原則
34
• オブジェクト間だけでなく、モジュール間でも同じことが
言える
• 依存が分離されていれば、リファクタリング、変更、障害、
再デプロイの影響が最小限になる
• 結合が弱くなることにより、拡張にも強くなる
Slide 36
Slide 36 text
3.5. 依存関係逆転の原則
Dependency Inversion Principle
35
Slide 37
Slide 37 text
依存関係逆転の原則
36
• 上位モジュールは下位モジュールに依存してはならない
• どちらのモジュールとも抽象に依存させるべき
↓
具体的なものは変わりやすいから
詳細に依存させないため
Slide 38
Slide 38 text
依存関係逆転の原則
37
Main
Task
TaskRepository
例) Todoアプリ(タスクを登録してDBに格納する)
Class Task {
public Task(String todo) {
this.todo = todo;
}
public save() {
TaskRepository r = new TaskRepository();
r.save(this);
}
}
Slide 39
Slide 39 text
依存関係逆転の原則
38
Main
Task
TaskRepository
依存関係を外部から注入する
Class Task {
public Task(String todo, Repository repo) {
this.todo = todo;
this.repo = repo;
}
public save() {
r.save(this);
}
}
Repository
Slide 40
Slide 40 text
依存関係逆転の原則
39
外部とは?
AbstractFactory(依存の注入)
本番用メイン
テスト用メイン
サービス
メインクラス(環境の注入)
Application Service
ServiceFactory
Slide 41
Slide 41 text
4. その他原則に関すること
SOLID原則だけがソフトウェア設計のすべてじゃない
40
Slide 42
Slide 42 text
コンウェイの法則
41
「システムを設計する組織は、その構造を
そっくりまねた構造の設計を生み出してしまう」
• ソフトウェアを作るのは人であるからチームの構造がソフ
トウェアの構造に反映される
• コミュニケーションをうまくとることでソフトウェアの品
質も上がる
Slide 43
Slide 43 text
GRASPパターン
42
• オブジェクト指向設計において用いられる、クラスやオブ
ジェクトに責務を割り当てる方針を導くパターンや原則であ
る。(Wikipediaより)
• 9個のソフトウェアに対する課題の質問と回答をまとめている
情報エキスパート 生成者
コントローラー 疎結合
高凝縮性 多態性
純粋人工物 変動からの保護
間接化
Slide 44
Slide 44 text
DRY原則
43
• Don’t Repeat Yourself. の略
• 「ソフトウェア開発においてすべての情報は単一で明確
な信頼できる表現になっていることが求められる」
• ソースコードだけでなくテストやビルドも対象
• コードであれば抽象化し、デザインパターンを活用する
• テストやビルドは自動化し、人間が何度も行わない
Slide 45
Slide 45 text
5. まとめ
全体のおさらい
44
Slide 46
Slide 46 text
まとめ
45
• オブジェクト指向での設計における原則としてSOLID原則
と呼ばれるものがある
• SOLID原則を意識しながらソフトウェア設計を行うと、拡
張性、メンテナンス性が高くなりやすい
• 全体の構成が洗練され、読みやすいコードを書くことが
できる
Slide 47
Slide 47 text
もうちょっとだけ
46
• 今回はオブジェクト指向における設計原則
• さらに上位のコンポーネントに関する原則もいろいろあ
ります
• 「Clean Architecture 達人に学ぶソフトウェアの構造と
設計」という書籍に目を通してみてください
Slide 48
Slide 48 text
ご清聴ありがとうございました!
ご質問がありましたらどうぞ
47