ここでプログラミングに関係する事をあまり書いてないと思いましたので、
今回タイトル通りの話をしたい＆皆さんの話を聞けたらいいなと思いました。

さて、デザインパターン…
私の中ではちゃんと使えたら便利だけど、
そうでないと振り回されておかしなことになるというイメージです。
なので「デザインパターンを駆使しないと！」という意識はあまり無いのですが、
色々なゲームを作っていてもほぼ必ず使うというのがありまして、それは以下の通りです。

【ほぼ必ず使うデザインパターン】
●シングルトン（Singleton）
デザインパターンを意識して使うようになったきっかけです。
若い（学生の）頃「デザインパターンなんて回りくどそう、使わなくても作れる！」と思っていましたが、
これを知って使ってみたら目から鱗が落ちたかのような衝撃でした。
それからデザインパターンを食わず嫌いすることが無くなったという思い出です。
私の中の認識は「C言語の関数の様な立ち位置のオブジェクトが作れる」で、
主にプレイヤーのデータなど、ユニークかつゲーム内全体で使うものや、
エラー管理などで使用しています。

●デコレーター（Decorator）
主に様々なキャラに共通する機能（ジャンプするとか）を後から付け足したり（または外したり）する時に、
継承とか関係なくやれるので重宝しています。
機能が多くなると、継承元とか肥大、複雑になりそうなので。
なのでキャラなどのオブジェクトを作るときはあまり継承とかさせずに、これを使うようにしています。

●ファサード（Facade）
キーボードやゲームパッドなどの入力周りで使っています。
これは初めて書籍かなんかで知ったときに、
入力周りで使うといいと書いてあったのをそのまま鵜呑みにして今も使っています。


逆にゲーム作成では一般的によく使いそうなもので、
私は使っていないのもあります。

【メジャーそうだけどあまり使いたくないデザインパターン】
●ファクトリー系（Factory）
一番よく使いそうなデザインパターンですが、
私には回りくどい感じが物色できずに使う意識が芽生えません。

●ステート（State）
昔1回使ってみたらクラスの両が半端無い数になって、
結局これを使わずに作り直したらすっきりした経験があってもう使わないと決めました。

●プロトタイプ（Prototype）
これもよく使われてそうで昔は私も使ってましたが、
発生するバグの原因の多くがこれに関するものだった経験があって、
今ではあまり使わなくなりました。
私と相性がよくないようです。


私からは以上です。
「よく使ってるのはこれで、こういう時に使ってます」とか
「前にデザインパターンを使ってみて失敗した」と言うような感じで、
よろしければ皆様の話も聞かせて頂けたら嬉しいです。

【ルール（というかマナーを含む）】
・ゲーム開発の話限定
・書籍に書かれている一般的な用途ではなく、実際に使用している上での話、経験談
・他の人の開発手法を否定・批判するのは控えて下さい。

メニュー画面でボタンが入力されたときのハンドリングにListenerをよく使います。
C#でいえばDelegateでしょうかね。

追記
そういえばチュートリアルの実装にメメントを使ったことがありました。
一歩前のステップに復元して同じ操作をやり直させるときとかにつかいます。

「ゲームです」っていうほどのものを作った経験は乏しいのですが…
私はシングルトンはむしろ要らない子という印象ですね．
不勉強だからでしょうが，何目的なのかいまいち不明なやつです．（少なくとも個人でやってる分には．）

データロード時に
ファイルに異常があったりして全部無事にロードできなかったときは，データが変わらないことを保証したい
という場合，簡単に考えれば
「仮のインスタンスA' にロードして，うまくいったら本当のデータ Aに，A=A' みたくして反映」すればいいのだけれど
それができなくなって結局書き換えた記憶しかない…

共有のためグローバルにせざるおえないリソース管理（画像や音）などでシングルトンは活躍の場があると思っているんですが、他にいい方法ありますかね。

今まさにオブジェクト指向に目覚めデザインパターンをここいらで勉強しています。
シングルトンで「おぉー。こんな存在があったのかー」と思いながら勉学を進めています。
あんまりグローバルにするんはよろしくない気もしますが、Cでいうstatic変数の変わりでしょうか。

http://marupeke296.com/DP_main.html

デザインパターンの本を購入しようかなぁと迷う日々です。

シングルトンはプラットフォームに依存するので基本的に使いません。
いわゆるアプリ(というよりガジェットに近いもの)はコンテキストに依存するので物理的に使えないのです。
必然的にファクトリーメソッドパターンも多用します。

データを外部化すると継承を使わなくなりますし、メモリ管理も必要なので、プロトタイプパターンに近いものを多用します。
デコレータパターンはメモリブロックを分断するので基本的に避けます。

基本的にはコンポジットパターン中心にまんべんなく使います。
実際のところデザインパターンが言われるようになる前から同じように作っているのであまり意識したことはありません。

FUNKさんの感想を読むとファサードパターン以外はわたしと用途が異なる感じがします。
プログラムの設計が異なっているということだと思います。
否定・批判ではないですよ。
わたしの場合は開発しやすさ以上に実行時の効率を優先しますから。

シングルトンはよく使っています。
というのも、グローバル変数がよりわかりやすい名前になるし、
Cxxx()->GetInstance()->... とあるだけで、あ、これはシングルトンだな
とわかりやすいからです。

Stateパターンも使ってました。
使ってましたというのも、状態を変更したいときにStrategyパターンと
組み合わせないと、状態を変更できなくなり、２つを組み合わせると
ソースコードが手に負えなくなり、結局 switch(). case文になりました。
きまればかっこいいんですが、読みやすさ、メンテナンス性を
とりました。

あとは、Decoratorパターンでしょうか。
後から機能追加するときに便利でした。
しかし、個人で開発しているので、そこまで恩恵はありませんでした。
すぐに書き直せばいいからです。

どうにも不勉強なので，StateだのStrategyだのBridgeだのいうのが全部同じものにしか見えない．
なので，「今使ってるのが○○パターンだぜ」とか意識というか認知してないのですが，ダメですかね．
（少なくともこういう場で会話できない，という点においてはダメですがｗ）

あと，批判とか否定ではなく，純粋にシングルトンの利点が知りたいです．
何故使うのか？　いつ使うのか？
例えば， GetXXXInstance() の先がどうなってるか：シングルトンなのか違うのか
については，この関数を呼びだす側にはあずかり知らぬことですし，それでいいと思っています．
なんというか，インスタンスを（そうそう簡単には）勝手に作れなくするとか，コピーできなくするとかしておけば
インスタンスの個数については，２個作りたくなければ２個目を書かなければいいだけな気が．
実装を真に「単一インスタンスを保証」する形にすると，こういういいことがあるよ，という場面というか
そういうのって，どういうときなのでしょう？　多人数開発時の牽制(?)とかでしょうか．

よくある単にDirect3Dデバイスをシングルトンにするとかはまったく無意味ですよね。
わざわざクラスにして生まれるメリットは、言語レベルであらゆるプラットフォームで共通に使えるとか拡張が容易だとかそういうところです。
ゲームプログラミングでシングルトンの例としてしばしばあげられるものはどれもこれも不適切なものばかりだと思います。

唯一のインスタンスを保証したいのはシステム設計側の思惑であって、利用側がそれを期待したコードを書くと単に汎用性を下げるだけです。

Direct3Dはデバイスのインターフェースを取得してインターフェース経由でメソッドを呼び出すというAPIの仕様で、OpenGLは同一スレッドであればどこからでも呼び出すことができるというAPIの仕様ですから、Direct3DとOpenGLの共通フレームワークを設計するとしたら、コンテキストを取得する関数を用意して、Direct3Dの場合は唯一のデバイスを返すシングルトンとして実装し、OpenGLは何も返さない(ダミー)実装になる、という感じです。

　自分はFlyweightパターンで画像を複数回読み込むこと等を防止しているつもりです。そのFlyweightも一種のシングルトンであると自分は思ってますし、そんな実装をしていたと思います。