Specificationパターン

仕様を満たしているかどうかを判定のみを行う専用のclassを定義する

Speficicationパターンを使わない場合を考えると、制約のせいでObjectの設計が歪められることがある

例えば、制約を評価するために、本来であればobjectの定義に合わないデータが必要になる。など

こういう時は無理にobjectを歪めるのではなく、その「制約を表したEntity」のようなものを別で定義する

これのことをSpecificationパターンと呼ぶ

複数のEnityにまたがったチェックができる

だいぶOOPが前提の話

OOPのやり方に沿うようなハックにも見える

fpだと、classではなくmoduleの話になるだろうか

3種類ある

検証

Entity、ValueObjectのvalidationを行う

booleanのmethod

選択

コレクションから特定のobjectを抽出するfiltering機能

コレクションが全部メモリ内に入っているなら簡単

ではDBに入っている場合はどうすればいい？

特殊なクエリメソッドをrepositoryに追加する

それをSpecificationから呼ぶ

repositoryの1つ1つのmethodは汎用的にする

Specificationの立ち位置がやっぱちょっとおかしい気が線でもない

それを無理やり合わしている感じがする

生成

文章が全然頭に入ってこない

何かの要求に適合する新しいオブジェクトを生成

参考

具体例があってわかりやすい