laravelとデザインパターン(GOF)
そもそもGOFデザインパターンってなんですか？
1994年に「オブジェクト指向における再利用のためのデザインパターン」という本の中で、プログラムで使えるパターンを23個まとめた物です。
GOF(gang of four)は日本語で言うとイケてる4人組みたいな意味で、4人組のグループをこのパターンを23個まとめた感じみたいです。
GOFデザインパターンについて
共通認識として知識があると、このパターンで作ってor作ってるよって言われた時にすぐ認識できたりします。
なので知識としてもっていると便利です。
全てのパターンを全て組み込むと良いと言う物ではないです。パターン化するより、よりシンプルな方が作成コストや管理コストが下がる場合があります。
またこのデザインパターンが1994年に作られたものであり現在は、優秀なフレームワークもあるので、その中でどのように使うと便利か？を考えるのがよさそうです。
ですので今回はlaravelでGOFデザインパターンって形でまとめてみます。
GOFのデザインパターンを学ぶ前の前知識
よくビジネスロジックって言う言葉がでてきます。ビジネスロジックって何よってなると思うのですが
- プレゼンテーション層→フロントとのデータのやりとり（viewで描画して→コントローラでデータを受け取るまで）
- データアクセス層→データアクセスする為のロジック
- ビジネスロジック→プレゼンテーション層・データアクセス層以外
正直プレゼンテーション層とビジネスロジックの担当の分離が分かり辛いです。
というか、見解わかれそうです。
という事で僕なりの例で出します。
ビジネスロジックの例
準備中
laravelでよく使えわれるデザインパターン
repositoryパターン
データアクセスとビジネスロジックを分離する目的で使われます。
repository IFと一緒に使われる事がおおいです。
参考下記
Facadeパターン
色々なクラスをまたがって処理するクラスです。
laravelにもファサードがありますが、こちらもFacadeパターンを使用してます。
interactor
ビジネスロジックをカプセル化するパターンで、一つの役割のビジネスロジックをまとめるパターンです。
記事を投稿するや、動画を投稿する等のそれい上分割できない単位を請け負うパターンになります。
～Service名前で作成される事が多いです。
railsではコントローラとモデルの間のレイヤで、複数のモデルにまたがるビジネスロジックを実装する場所とされています。
近いHelperクラスがありますが、Helperは手助けをするクラスで、単位を揃えるや、,を入れる等手助けをするクラスになります。
railsはviewをdry実装する為に仕様するクラスになったりします。
- Helperは各modelで色んな所から呼び出される使い方
- serviceは色んなモデルを跨って処理するビジネスロジックを実装する場所
と考えると分かりやすいです。