仕様(Specification)

前回仕様について読んでいくなかで、仕様パターンには、

の３つのパターンがあるということでした。検証まで読んだので、選択・要求について読んでいきます。

選択(問い合わせ)

コレクションから、一部を選び出すというものですね。

コレクションがメモリ上にあるか、RDB上にあるかというはここでは問いてはないですね。クライアントからはどちらか意識しなくていいように実装するのはRepositoryの章で読んだとおり。

例では、Repositoryに仕様オブジェクトを渡してSQLを返したり、仕様オブジェクトにRepositoryを渡して選択されたコレクションをRepositoryから取得するとかしています。

自分がよく実装しているパターンは選択の条件をまとめた「Criteria」クラスをRepositoryに渡して、インフラストラクチャ層でCriteiraを元にSQLを構成、実行し、コレクションを返すといったことをしています。

SQLを組み立てる支援があるツール（MyBatisなど)を利用すれば、容易に実装が可能です。

Criteriaが仕様クラスになる感じですね。

要求は生成時に条件を指定して、条件に従ったオブジェクトを生成するというパターンですね。

書籍の例では、コンテナにどんな化学製品を入れるかによって、別々のコンテナを生成するといった例が上げられています。

こちらも条件をコンテナ自体が持つのではなく、コンテナ仕様クラスが持つということをしていますね。

この章の最後に表題とは無関係ながら、面白いコラムが載っていたのでご紹介。

他のチームの実装を待ったり、ユーザーからのフィードバックを待ったりする停滞を避けるため、インターフェイスを活用して、実装と分けることで、一旦動くプロトタイプを作成しておいて、後からしかるべき実装に置き換えるといったことが紹介されています。

こういうのを活用すればなかなか分離しにくいユースケースやストーリも分割して進められることができますね。