デザインパターン入門

デザインパターンとは
● 設計のノウハウを再利用するために考えられた、定石のようなもの。
● GOFの23種類のパターンが有名
● この23パターン全部を覚える必要はないが、主要なものは覚えたい

例えば・・・
商品データを繰り
返し使うのでキャ
ッシュしたい
どうしましょう？

Decoratorパターン
商品データ収集クラスを拡張して、キャッシュ機能を付けても間違いではないですが・・・
キャッシュ機能のクラスを作り、
データ収集インタフェースを実装する
こうすると、データ収集インタフェースを
使う人は、同じインタフェースでキャッシ
ュ付きの商品データ収集が出来る

Decoratorパターンは拡張(子クラス)より良いの？
● 別のデータ収集(売上データ等)でもキャッシュ機能が欲しくなったら？
→クラスを追加せずにキャッシュ機能を使える
● 他の機能(ソート、フィルター等)が欲しくなったら？
→ソート機能を作れば、キャッシュ+ソート機能付きのデータ収集ができる

改めて、デザインパターンのメリット
● 先人が考えたより良い設計のアイデアを、誰でも使うことが出来る
● 他の人と設計時のコミュニケーションに使える

キャッシュは共有したい
キャッシュ機能付きの商品データ収集を実装した
→使うたびにインスタンスを作ると、キャッシュが共有されない
アプリ全体で商品データのキャッシュは共有したい

Singletonパターン
● アプリ全体でインスタンスが1つであることを保証する
● 基本的にグローバル変数と変わらないので、乱用に注意
● 状態が変わらないインスタンスの場合は使いやすい

煩雑なオブジェクトの生成
商品データ一覧表をExcelで出したい(出力形式は画面で設定)
各インスタンス構成的にはこんな感じ？
いくつものインスタンスを作らな
ければならず、一つ一つ作って行
くのが面倒

Factory Methodパターン
商品データ一覧表出力のインスタンスを作るFactoryクラスを作る
使用者が、コンストラクタよりも
楽にインスタンスを作れる

staticなFactoryメソッドはあり？
● Factoryクラスをインスタンス化できる=ポリモーフィズムで使える
● そうしないのであればstaticなFactoryメソッドもあり

大まかな処理の流れが共通な処理
大まかな処理の流れが同じ場合に、それぞれを別のクラスとして実装すると、
同じ処理を各クラスに記載することになってしまう。
各保存処理は、
● ヘッダ設定
● ボディ部の各行設定
● フッタ設定
という流れは共通している

Template Methodパターン
大まかな処理の流れを親クラスだけで実装し、
そこから呼び出される各処理を抽象メソッド化
各抽象メソッドを子クラスで実装する

まとめ
● デザインパターン＝設計ノウハウ集
● とりあえずGOFの23のパターンは確認してみましょう

Recommended