あなたは、どれが好いと思います? それはなぜ?

設計にあわせて、必要になったときに、必要な部分に、
必要なものを、必要なだけ使えばいいんじゃないでしょうか。

特にGoFのパターンは「似たものを独自に再設計/実装する」くらいなら
合わせた方がいい(かもしれない)実装の典型例であって、
最初に何かを「選択」するものとは思えません。

所詮はイディオムみたいなもので、一つしか使えないとか、何かを選択しなくちゃ、
とかいう代物でもないわけで、
方式が固まってもっと具体的な話に落ちてから考えれば十分に思いますし、
先にもっと大きな部分で要件を定義したり、
アーキテクチャを設計したりするべきだと思います。

そもそも、「どの要求がどこまで必要か」という背景情報(要件/目的)の
分からない人間には絶対選択できないものとかもありますし＞デザパタ

例えば、書き捨てで将来にわたって変更予定がまったくないなら
Strategyパターンは無意味なわけですが、少なくとも私には判断材料がありません。
また「将来変更されうる部分はStrategyパターンを使っておいた方が安全ですよ」と
漠然といわれても本に書いてあることそのままで、あまり意味があるとも思えません。

設計時からそういうのにこだわり *すぎる* と、オーバスペックでロスの多いものに
なる可能性もありますので、特に最初は、
・(あまりパターンに拘らずに自分の目的に合わせて)まず方式を考える
・その後で、デザパタが適用できそうな場所があればそこにそれを適用する
という方向性の方がよいのではないかと思います。

私も概ね他の方が書かれているのと同じですが、

常々うちのメンバーに言っているのは、
「デザパタに使われるようになるな」
って事ですね。

デザパタは設計上こう言うパターンになる事が多いよという例を
まとめた物と言うイメージなのでまずデザパタありきではなくて
やりたい事を実現しようとしてみたらどうもこのパターンでいけそう
という使い方だと思います。
必ずしもデザパタを使わないといけないというわけでは無いので
デザパタに拘るあまりデザパタに使われてしまうようだと逆効果だと
思いますよ。

もともとデザパタをあまり気にしていない、私が言うのもなんですが

＞イベントドリブン方式でユーザは、刻々と要求データ数が増えたり、減ったりと変化
していきます、

具体的に、どんなイベントを受け取るつもりでいますか？
つまり、イベントを受け取らない限り、ＰＧは何も動作しない（待機）状態にある
と説明していますよね？

基本デザパタは１つなのかも知れませんけど、要求イベントによっては
同一ＰＧ内で、パターンは変化するものと思われますが
パターンの変化をしてはいけない等の要求をされているんですか？

バッチ処理方式であれば、通り一辺倒の考え方でよいかもしれませんが
イベント方式では、あまり型にはまりすぎるのもどうかと思いますよ？

型にはまりすぎて、オーバーヘッドを食わせすぎて、処理速度をおろそかに
してしまいがちになりますよ

他言語ですが、数行のコードで済むものを、型にはめたい、ために数百行のコードに
展開してた例も少なくありませんよ

うーーん、

まず、大事なことは
　　　「顧客が何を求めているか？」
ということだとおもいます。

その後、
　　　１．「ソフトでどうのようなことが実現できるか？」
　　　２．「使えそうなデザパタをさがす。」
です。

皆さんの意見の通りに、
　　　「デザパタありきではない。」
ということだと思います。

あ！　訂正です

誤
＞　　　１．「ソフトでどうのようなことが実現できるか？」

正
　　　１．「顧客の要望に対してソフトでどのように実現するか？」
ですね。
ここら辺の語句は表現が難しいですね。