昔からデザインパターンは勉強しておりましたが、使い所などで悩むことが多かったです。
現在の現場でいろいろなパターンを見させていただき、なんとなくではありますが使い所がわかったので、まとめてみようと思います。
Factoryパターン
インスタンス生成をFactory内部で行うことで疎結合化させることができます。
使い所はテストデータの構築などで一部のステータスや状態変化系のパラメータだけ変えたい時など。
Facadeパターン
窓口を簡潔にすることで、アプリ本体とライブラリを疎結合状態にすることができる。インスタンス作成を不要にできる。
使い所としては、外部のライブラリを読み込み、それを使うときなど。
Observeパターン
特定のモデルを監視し、何かのイベントをトリガーとして、起動するパターン。
使い所としてはLogの仕込みや履歴系のテーブルの保存など。
ただし、通常のプログラムとは別の場所に処理を書くため、動きを把握しきれないというデメリットもあり。類似の処理としてevent-linsterなど
Stateパターン
状態遷移の担保など。
おもにstatusなどの状態を表す値でつかうことが多い。一定のステータスから一定のステータスへの変更がありえるか、ありえないかなど。
ファーストコレクション
在庫状態や予約データなど、変数や配列でもたせるだけでは足らず、メソッドなども併せて、複雑な状態を表現するときに使用。
シングルトンパターン
インスタンスの生成を１つにできる。
グローバルな値を使いたいとき。かつメモリやCPUの消費を抑えられるというメリットがある。オブジェクト指向ではあまりないかも・・・
Repositoryパターン
Service層と値オブジェクト、Modelなどのはしわたしをします。
大きい効果を発揮する箇所としてはキャッシュとDBで処理を分けたいとき。
要は参照系の処理はアクセスが多いため、Redisなどのキャッシュを使い、更新系の処理などはDBを見なくてはいけない。。。のようなときにIFは共通なんだけれども、実装を分けたい場合に便利です。
