設計パターン-標準ソリューション、対抗策-典型的な設計エラー。 デザインパターンについては十分な本が書かれていますが、アンチパターンについてはほんの数冊しか書かれていません。 これらのアンチパターンの1つを説明するSourceMaking Webサイトの記事の無料翻訳をご紹介します（サイトのSoftware Development Antipatternsセクションには14個あります）。
名前： Poltergeists（poltergeists）
他の名前：ジプシー（ジプシー）、クラスの増殖（クラスの数の増加）、Big DoIt Controllerクラス
スケール：アプリケーション
リファクタリング：ゴーストバスティング（ゴーストバスティング）
理由： OOP概念の理解不足、クラスアーキテクチャを考えるのが面倒
注：翻訳の著者は、デザインの第一人者であると主張することは決してなく、したがって、道徳的に触れることで記事を知覚しないように求めます。 この記事の主な目標は、問題の本質をより深く理解し、場合によっては、記述された状況がどれほど重要であるかを知ることです。
背景
Gypsiesという名前で検討中のアンチパターンは、1996年のObject World WestカンファレンスでMichael Akroydによって初めて導入されました。 Ackroydは、このアンチパターンの動作が、突然現れてから突然消えるジプシーの遊牧生活に似ていることを発見しました。 アンチパターンの名前にその本質についてのより多くの情報を伝えるために、「ポルターガイスト」という別の名前を選択しました。 これらの「落ち着きのない幽霊」は、独自の孤立したナイトライフを導きます。 この用語は、このアンチパターンの「何かをするために覗く」という概念をよりよく表し、同時に元の名前の「ここにあるが、もう存在しない」という隠metaを保持します。
LISPプログラマー（および他のプログラマー）の中には、プログラミング言語の多くの機能の「副作用」を最大限に活用して、システムで重要なタスクを暗黙的に実行する開発者がいます。 そのようなシステムの分析と理解は実際上不可能であり、再利用しようとする試みはしばしば無意味になります。
「副作用」の使用が言語ツールの誤った使用であるように、ポルターガイストクラスの出現も設計コンセプトの誤用の結果です。
説明
ポルターガイストは、責任が限定され、システム内で役割を果たしているクラスです。 効果的なライフサイクルは短いです。 Poltergeistsはソフトウェアアーキテクチャの調和に違反し、冗長な（冗長な）抽象化を作成し、過度に混乱し、理解しにくく、維持するのが困難です。
このアンチパターンは、デザイナーがモデリングプロセスに精通しているが、オブジェクト指向アーキテクチャの作成に十分な経験がない状況で一般的です。 それらのアーキテクチャーでは、一時的に表示される1つ以上のポルターガイストクラスを識別して、より永続的な（より長い寿命を持つ）別のアクションを開始することができます。 Ackroydはこれらのクラスをジプシーキャリッジと呼びます。 通常、このようなクラスは、他のクラスのメソッドを呼び出すためだけに存在するコントローラークラスと見なされます。多くの場合、あらかじめ決められた順序で呼び出されます。 通常、それらの名前は「_manager」 、 「_ controller」で終わることが多いため、明らかです。
アンチパターン「ポルターガイスト」の出現の犯人は、通常、オブジェクト指向設計の概念を完全に理解していない初心者の建築家です。 Poltergeistクラスは、次の3つの主な理由により、貧弱なアーキテクチャソリューションです。
- オプションであるため、「表示」されるたびに無駄にリソースを消費します。
- 冗長なナビゲーションパスを使用するため、非効率的です。
- 不必要にオブジェクトモデルをロードするため、適切なオブジェクト指向の設計を妨げます。
アンチパターンの外観と結果の兆候
- 過剰なナビゲーションパス。
- 一時的なアソシエーション（ 注：以下、「アソシエーション」の下では、UMLからの通信の関係が採用されます）。
- ステートレスクラス（メソッドと定数のみを含む）。
- 一時オブジェクトおよびクラス（存続期間が短い）。
- 一時的な関連付けを介して他のクラスを作成または呼び出すことのみを目的とする単一のメソッドを持つクラス。
- start_process_alphaなどの「コントロール」スタイルのメソッド名を持つクラス。
典型的な原因
- オブジェクト指向アーキテクチャの欠如（アーキテクトはオブジェクト指向のパラダイムを理解していません）。
- 問題を解決する方法の間違った選択。 一般的な意見に反して、オブジェクト指向アプローチは必ずしもすべてのタスクに適した唯一のソリューションではありません。 あるポスターが言うように：「間違いを犯す正しい方法はありません。」 検討中の問題について、これは、オブジェクト指向のアプローチが正しい選択でない場合、それを実装する正しい方法がないことを意味します。
- 要件分析段階（オブジェクト指向分析の前）でのアプリケーションアーキテクチャに関する仮定も、このアンチパターンと同様の問題につながる可能性があります。
リファクタリング
ポルターガイストの問題は、クラス階層からそれらを削除することで解決されます。 彼らが実行する「機能」を交換する必要があります。 これは通常、アーキテクチャを簡単に調整することで非常に簡単です。
ソリューションの鍵は、ポルターガイストコントローラー（カプセル化されている）の制御アクションを、ポルターガイストがメソッドを呼び出すクラスに転送することです。
例
パターンをより明確に理解するために、図の例を検討してください。
Peach Canner Controllerクラスは「ポルターガイスト」であることがわかります。
- 問題のシステム内の他のすべてのクラスへの冗長ナビゲーションパスがあります。
- 彼の協会はすべて黄褐色です。
- 彼には条件がありません。
- は、一時的な関連付けを介して他のクラスを呼び出すためにのみ存在する一時的なクラスです。
この例では、poltergeistクラスを削除すると、残りのクラスは相互作用する能力を失い、プロセスが実行される順序もなくなります。 したがって、相互作用の可能性を残りの階層に配置する必要があります。 各クラスが個別に対話して結果を処理するように、特定の操作が各プロセスに追加されることに注意してください。
関連ソリューション
Blobアンチパターンで説明されている「80％ソリューション」は、ポルターガイストアンチパターンに非常に似ています。 提示されたクラス「コーディネーター」は、システム全体またはそれ以上の機能を引き続き制御し、原則として多くのポルターガイストプロパティを持っています。
システムの他のスケールおよびレベルへの適用可能性
アンチパターンは、開発者がシステムの実装方法を設計するときに発生し（通常は「ズボンの座席で」 ）、システムアーキテクチャの構築の省略の結果として発生することもあります。
設計のほとんどのアンチパターンと同様に、アーキテクチャレベルと管理レベルの両方が、それらの防止とその後の戦いにおいて重要な役割を果たします。 アンチパターンの外観は、多くの場合、アーキテクチャの観点から正確に認識され、効果的な管理を通じて、この観点をすぐに検討する価値があります。
マネージャは、オブジェクト指向アーキテクチャが、作成の初期段階およびその後定期的に、資格のあるアーキテクトによって評価されるようにする必要があります。 これにより、このアンチパターンのような初心者の間違いを回避できます。 良いアーキテクチャの価格を前もって支払う方が良いでしょう。