| 生成系 |
| 共有オブジェクトが1つだけ必要で、複製すると不具合になる | | テストで差し替える必要があるもの(データベース、時計など)には使わないでください。そのようなものは代わりに引数として渡してください。 | 22 |
| 基底クラスが処理の流れを進め、どのオブジェクトを作るかはサブクラスが決める | | 作る製品のクラスが1つだけの場合は不要です。コンストラクターか静的ファクトリーで十分です。 | 32 |
| 複数のオブジェクトを同じ系統から作る必要がある(地域、テーマ、データベースなど) | | 製品の型が1種類だけの場合や、系統が混ざることがない場合は不要です。意味なくクラスが増えるだけです。 | 29 |
| 任意項目が多い。または、誰かが見る前にオブジェクトが正しい状態である必要がある | | 必須の項目が2-3個だけのrecordには不要です。標準のコンストラクターのほうが分かりやすいです。 | 37 |
| 新しいオブジェクトは、設定済みのひな形をコピーして作る | | オブジェクトの生成コストが低い場合は不要です。また、変更可能なフィールドの浅いコピーに注意してください。 | 28 |
| 構造系 |
| 編集できないクラスのインターフェースが合わない | | 両側のコードを自分で管理しているなら不要です。変換役を追加する代わりに、インターフェースを変更してください。 | 28 |
| 2つの要素がそれぞれ独立に変化し、サブクラスが増えていく(種類×チャネル) | | 2つの軸のどちらかにバリエーションが1つしかない場合は不要です。 | 31 |
| 1つの要素とまとまりを、同じように扱いたい木構造 | | データがフラットな場合や、末端とまとまりに必要な操作が大きく異なる場合は不要です。 | 25 |
| 任意の振る舞いを、実行時に好きな組み合わせで追加したい | | 追加機能の適用順が結果に影響してはならない場合は不向きです。ラッパーは積んだ順に適用されます。 | 30 |
| 呼び出し側で、同じ複数ステップの手順が複数のクラスに繰り返し書かれている | | すべてのロジックを隠す場所としては使わないでください。ファサードは調整役であり、何でも持つゴッドクラスになってはいけません。 | 46 |
| 同じ重いデータを持つオブジェクトが何千も存在する | | オブジェクトの数が少ない場合や、共有できる部分が小さい場合は不要です。得るものが少ないのにファクトリーを追加することになります。 | 32 |
| 呼び出し側を変えずに、遅い・遠隔にある・保護された対象へのアクセスを制御したい | | 追加の層が、呼び出し側が対処すべき失敗を隠してしまう場合は不向きです(「ローカル」に見えるインターフェースの裏に隠れたネットワークエラーなど)。 | 33 |
| 振る舞い系 |
| リクエストを、処理できるハンドラーが見つかるまで順に渡していく | | 必ず1つの決まったハンドラーだけが適用される場合は不要です。直接呼び出したほうが分かりやすく、デバッグもしやすいです。 | 26 |
| 操作を、キューに入れる・記録する・再試行する・取り消す必要がある | | キューに入れたり取り消したりしない一度きりの呼び出しには不要です。余計な手間が増えるだけです。 | 44 |
| ユーザーが、評価しなければならない小さな言語でルールや数式を書く | | 大規模または頻繁に変わる言語には不向きです。パーサージェネレーター(ANTLR)や既存の式エンジンを使ってください。 | 56 |
| 保存方法を知らなくても、要素を順にたどりたい | | Streamや既存のコレクションで必要なものがすでに得られる場合は不要です。 | 30 |
| 多くのオブジェクトが互いに参照し合い、依存関係が絡み合っている | | メディエーターが肥大化して、すべてのロジックを抱え込むゴッドオブジェクトになる場合は不向きです。 | 37 |
| フィールドを外に公開せずに、オブジェクトの状態を保存・復元したい | | スナップショットが大きく頻繁に作られる場合は不向きです。代わりに変更内容(コマンド)を保存してください。 | 36 |
| 1つのオブジェクトが変わったとき、ほかのオブジェクトが反応する必要がある | | 反応を厳密な順序で、または1つのトランザクション内で行う必要がある場合は不向きです。その場合は直接呼び出してください。 | 30 |
| 振る舞いが状態によって変わり、どのメソッドも状態で分岐している | | 状態が2-3個で単純なルールの場合は不要です。列挙型とswitchで十分です。 | 42 |
| 同じ仕事を行う複数の方法があり、実行時に入れ替えて選びたい | | 変わることのないアルゴリズムが1つだけの場合は不要です。 | 24 |
| 同じ順序の手順で、一部の手順だけが異なる | | 手順が自由に変わる場合は不向きです。継承を強いる代わりに、ストラテジーを渡してください。 | 34 |
| 型の定義を変えずに、決まった型の集合に新しい操作を加えたい | | 型の種類が頻繁に変わる場合は不向きです。新しい型を追加するたびに、すべてのビジターを修正する必要があります。 | 52 |