目次
- デザインパターンの説明
- Facadeパターン
- Strategyパターン
- デザインパターンまとめ
- 参考文献
デザインパターン（概要）
- GoFという頭のいい人が考えた全23パターン
- 対象はオブジェクト指向言語
- 他にもいくつかの種類がある
- Javaの機能を活用して（主に）拡張性の向上を図っている
- 継承
- ポリモーフィズム
- カプセル化など
- 優秀なベテランはこう考えている！という考え方集
- 具体的な実装方法ではない
- 考え方を理解して自分のプログラムに応用
デザインパターン（効果的な使い方）
- 考え方を応用して自分のソースに反映する
- ≠パターンに合わせて実装する
- 効果が期待できる場合のみ使う
- ≠可能な限り適用する
- ≠デザインパターンの効力を妄信する
- 無理に使うと逆効果
- 状況に合わせて柔軟に適用判断する
- ≠設計時に適用判断をしたのでプログラムに絶対に反映する
デザインパターン（メリット・デメリット）
メリット
- 拡張性向上 オブジェクト指向の活用
- 再利用性向上 オブジェクト指向の活用
- 可読性向上 オブジェクト指向の活用・共通認識
- 伝達速度向上 共通認識
デメリット（問題点／リスク）
- 現在の思想・仕組みとの乖離（一部）
- 生産性低下
- パターンへの固執
- コードの複雑化
- 解釈の違いによる誤解や不要な議論（抽象的であるため）
デザインパターン（活用タイミング）
- クラス設計時
- リファクタリング時
- レビュー時
- レビュアーへの説明時間の短縮
- 双方がパターンを知っている場合のみ
- レビュアーへの説明時間の短縮
- プログラミング調査時
- 読み解き時間の短縮
- 予測精度の向上
- パターンを知っている場合のみ
- プログラミング修正時
今回取り上げる2つのパターン
- 以下の観点でピックアップ
- 理解が容易
- 活用が容易
- 一定の効果が見込める
- 身近に例がある
- Facadeパターン
- Strategyパターン
Facadeパターン（概要）
- 複雑な処理の流れをクライアントの代わりに担うクラスを作成
- クライアント側はFacadeクラスを呼ぶだけで複雑な処理が可能
- クライアント側の処理がシンプルに
- 一般的に最も使用されているパターンで、ある程度無意識に仕様
- リファクタリングにも非常に有用
Facadeパターン（活用条件）
- 一連の処理で様々なクラスのそっどを呼ぶ必要がある
- 多数のクライアントから呼ばれる一般的な処理である
Facadeパターン（登場人物）
- Client
- 複雑な処理を実行したいクラス群
- Facadeクラスを呼び出す
- Facade
- 複雑な処理呼び出しを引き受けるクラス
- 実クラス群を呼び出す
- 実クラス群
- 複雑な処理の一部分を引き受けるクラスの集まり
- Facadeクラスに必要なタイミングでそれぞれ呼ばれる
Facadeパターン（イメージ）
Facadeパターン（メリット・デメリット）
メリット
- クライアントの簡素化による可読性向上
- 処理の追加・修正・削除の簡易化
- クライアントの追加・削除の簡易化
デメリット
- 不要なFacadeクラスの量産
Facadeパターン（まとめ）
- 複雑な処理をまとめて一つのクラスで実施
- クライアント側と処理の追加が容易になる
- 割と簡単に適用できる
- 用途を絞らないと無駄なクラスが増えて逆効果
Strategyパターン（概要）
- 条件分岐で処理を切り替えている部分をサブクラス化
- 条件増加時の既存ソースへの追加が最小限
- Stateパターンと酷似
Strategyパターン（登場人物）
- Strategy
- 戦略を利用するためのインターフェース
- 処理の種類定義と型の再利用を担う
- ConcreteStrategy
- Strategyの実装
- 実際の処理を担う
- Context
- Strategyを利用するクラス
- Strategy型の変数を持つ
- Strategy型の処理を呼び出すが実態は把握しない
- Client
- ContextにStrategyの型を渡す
- Contextの処理を呼び出す
Strategyパターン（活用条件）
- 条件分岐で類似処理を呼び出している
- 将来的に条件の増減が見込まれる
Strategyパターン（イメージ・未利用時）
Strategyパターン（イメージ・利用時）
Strategyパターン（メリット・デメリット）
メリット
- 処理Class追加時の影響範囲が明確
- 既存処理を修正しないため
- プログラム全体の処理把握が容易 ## デメリット（リスク）
- 無理な適用によるコードの複雑化
Strategyパターン（まとめ）
- 条件分岐で類似処理が走る場合に使用
- 既存ソースの影響範囲が絞れる
- Facadeよりちょっと面倒で複雑
- 処理の追加が見込まれない場合は労力の方が大きい
デザインパターン（まとめ）
- オブジェクト指向を活用して拡張性と再利用性を高めよう
- 可読性も上がる（こともある）
- そのまま使うのではなく考え方を当てはめる
- 組み合わせも可
- 〇〇パターンで！だけで通じると意思伝達が早くて楽
- 元がざっくりしたものなので解釈の違いがある
- 今回読んだ本でも解釈が異なるものがあった
- やりすぎると労力＆工数の無駄
参考文献（敬称略）
- Java言語で学ぶデザインパターン
- 著者：結城 浩
- Javaデザインパターン徹底攻略
- 著者：日本ソフトウェアエンジニアリング（株）
- リファクタリング 既存のコードを安全に改善する
- 著者：Martin Fowler
- 訳 ：児玉公信・友野昌夫・平澤章・梅澤貴史
- 事例で学ぶデザインパターン
- 劇的ビフォ◯アフターで学ぶデザインパターン
- 著者：karoten512
- URL：http://karoten512.hatenablog.com/entry/2017/10/21/134048