Javaのデザインパターン

# 目次

1. デザインパターンの説明　
1. Facadeパターン
2. Strategyパターン
3. デザインパターンまとめ
4. 参考文献

- - -

# デザインパターン（概要）

- GoFという頭のいい人が考えた全23パターン
    - 対象はオブジェクト指向言語
    - 他にもいくつかの種類がある
- Javaの機能を活用して（主に）拡張性の向上を図っている
    - 継承
    - ポリモーフィズム
    - カプセル化など
- 優秀なベテランはこう考えている！という考え方集
    - 具体的な実装方法ではない
    - 考え方を理解して自分のプログラムに応用

---
#デザインパターン（効果的な使い方）

- 考え方を応用して自分のソースに反映する
    - ≠パターンに合わせて実装する
- 効果が期待できる場合のみ使う
    - ≠可能な限り適用する
    - ≠デザインパターンの効力を妄信する
    - 無理に使うと逆効果
- 状況に合わせて柔軟に適用判断する
    - ≠設計時に適用判断をしたのでプログラムに絶対に反映する

---
# デザインパターン（メリット・デメリット）

## メリット
1. 拡張性向上　　オブジェクト指向の活用
2. 再利用性向上　オブジェクト指向の活用
3. 可読性向上　　オブジェクト指向の活用・共通認識
4. 伝達速度向上　共通認識

## デメリット（問題点／リスク）
1. 現在の思想・仕組みとの乖離（一部）
2. 生産性低下
    1. パターンへの固執
    2. コードの複雑化
    3. 解釈の違いによる誤解や不要な議論（抽象的であるため）

---

# デザインパターン（活用タイミング）

- クラス設計時
- リファクタリング時
- レビュー時
    - レビュアーへの説明時間の短縮
        - 双方がパターンを知っている場合のみ
- プログラミング調査時
    - 読み解き時間の短縮
    - 予測精度の向上
        - パターンを知っている場合のみ
- プログラミング修正時

---

# 今回取り上げる2つのパターン

- 以下の観点でピックアップ
    - 理解が容易
    - 活用が容易
    - 一定の効果が見込める
    - 身近に例がある

1. Facadeパターン
2. Strategyパターン

---

# Facadeパターン（概要）
- 複雑な処理の流れをクライアントの代わりに担うクラスを作成
- クライアント側はFacadeクラスを呼ぶだけで複雑な処理が可能
    - クライアント側の処理がシンプルに
- 一般的に最も使用されているパターンで、ある程度無意識に仕様
- リファクタリングにも非常に有用

---
# Facadeパターン（活用条件）

- 一連の処理で様々なクラスのそっどを呼ぶ必要がある
- 多数のクライアントから呼ばれる一般的な処理である

---

# Facadeパターン（登場人物）
- Client
    - 複雑な処理を実行したいクラス群
    - Facadeクラスを呼び出す
- Facade
    - 複雑な処理呼び出しを引き受けるクラス
    - 実クラス群を呼び出す
- 実クラス群
    - 複雑な処理の一部分を引き受けるクラスの集まり
    - Facadeクラスに必要なタイミングでそれぞれ呼ばれる

---

# Facadeパターン（イメージ）
![図1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531245/f8f13d08-3ef9-c336-4156-125c2d649f2f.png)

---

# Facadeパターン（メリット・デメリット）

## メリット
1. クライアントの簡素化による可読性向上
2. 処理の追加・修正・削除の簡易化
3. クライアントの追加・削除の簡易化

## デメリット
1. 不要なFacadeクラスの量産

---
# Facadeパターン（まとめ）

- 複雑な処理をまとめて一つのクラスで実施
- クライアント側と処理の追加が容易になる
- 割と簡単に適用できる
- 用途を絞らないと無駄なクラスが増えて逆効果

---
# Strategyパターン（概要）

- 条件分岐で処理を切り替えている部分をサブクラス化
- 条件増加時の既存ソースへの追加が最小限
- Stateパターンと酷似

---
# Strategyパターン（登場人物）

- Strategy
    - 戦略を利用するためのインターフェース
    - 処理の種類定義と型の再利用を担う
- ConcreteStrategy
    - Strategyの実装
    - 実際の処理を担う
- Context
    - Strategyを利用するクラス
    - Strategy型の変数を持つ
    - Strategy型の処理を呼び出すが実態は把握しない
- Client
    - ContextにStrategyの型を渡す
    - Contextの処理を呼び出す


---

# Strategyパターン（活用条件）

- 条件分岐で類似処理を呼び出している
- 将来的に条件の増減が見込まれる

---
# Strategyパターン（イメージ・未利用時）
![図2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531245/00a00ab7-4971-6943-7083-011e62b3ae17.png)

---

# Strategyパターン（イメージ・利用時）
![図3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/531245/18a6468b-e5af-d54c-5d55-eea0709ebb10.png)

---

# Strategyパターン（メリット・デメリット）

## メリット
1. 処理Class追加時の影響範囲が明確
    1. 既存処理を修正しないため
    2. プログラム全体の処理把握が容易
## デメリット（リスク）
1. 無理な適用によるコードの複雑化

---
# Strategyパターン（まとめ）
- 条件分岐で類似処理が走る場合に使用
- 既存ソースの影響範囲が絞れる
- Facadeよりちょっと面倒で複雑
- 処理の追加が見込まれない場合は労力の方が大きい

---

# デザインパターン（まとめ）
- オブジェクト指向を活用して拡張性と再利用性を高めよう
- 可読性も上がる（こともある）
- そのまま使うのではなく考え方を当てはめる
    - 組み合わせも可
- 〇〇パターンで！だけで通じると意思伝達が早くて楽
- 元がざっくりしたものなので解釈の違いがある
    - 今回読んだ本でも解釈が異なるものがあった
- やりすぎると労力＆工数の無駄

---
# 参考文献（敬称略）

- Java言語で学ぶデザインパターン
   - 著者：結城 浩
- Javaデザインパターン徹底攻略
   - 著者：日本ソフトウェアエンジニアリング（株）
- リファクタリング　既存のコードを安全に改善する
   - 著者：Martin Fowler
   - 訳　：児玉公信・友野昌夫・平澤章・梅澤貴史
- 事例で学ぶデザインパターン
   - 著者：福田 直樹
   - URL：https://www.ogis-ri.co.jp/otc/hiroba/technical/DesignPatternsWithExample/
- 劇的ビフォ◯アフターで学ぶデザインパターン
   - 著者：karoten512
   - URL：http://karoten512.hatenablog.com/entry/2017/10/21/134048