調べていくとあの時もっとこうしておけば良かったこの困ったところはこういう風に書けるんだと思うようなことが多々あったので、まとめていこうと考えました。気をつけたいこと「デザインパターン厨」という言葉もあるぐらいデザインパターンにこだわり過ぎることに気をつけ、デザインパターンはあくまでもわかりやすいコードを書くための良い参考例として学んでいきたいと思います。Principleクラスは拡張に対して開いており、修正に対して閉じていなければならない既存のコードに修正を加えずに、拡張のためにコードを追加することで変更によるバグを起きにくくするという方針のことのようです。検索条件を指定するという場面を考えたいと思います。red}さらに、生産地による検索条件を追加しようとする場合、FruitFilterクラスに新たにメソッドを加えます。result}では、生産地と色が検索条件の場合は?となるとまたメソッドが増え、クラスはどんどん大きくなっていってしまいます。小さいうちはいいですが、大きくなってくると見辛くなり、もしかしたら予期せぬ箇所への影響を与えることもあるかもしれません。Principleを適用してみたいと思います。Specification(仕様)パターンDDD本で紹介されているパターンで・入力チェックなどのバリデーション(検証)・集合(配列、リストなど)から特定の要素を抽出する(選択)・条件を満たした新しいオブジェクトを作る(生成)などに用いられます。small}複合条件の場合は以下のようにします。今後条件の追加が起こったとしても既存のコードに変更を加えずに拡張が可能になり、オープンクローズド原則に沿った形になりました。悩んでいるところAND条件を可変にしたい場合、以下のような実装が思い浮かびます。domestic}何かもっと簡単に書ける方法があるような気がします。アドバイスなどございましたら大変うれしいです。まとめデザインパターンという型を通して具体的な例の作成や過去に行っていた実装を書き換えてみるなどを行うことでだんだんと理解を深めることができました。使いどころを見出し、コーディング時の選択肢の1つとして使えるようにしていきたいと思います。