アンチパターンとは何ですか？
パターンとアンチパターンを研究しています。私はパターンについて明確なアイデアを持っていますが、アンチパターンは得られません。ウェブとウィキペディアの定義は、私をとても混乱させます。
誰もがアンチパターンとは何かを簡単な言葉で説明できますか？目的は何ですか？彼らは何をしますか？それは悪いことですか、良いことですか？
Anti-patterns は、不適切なプログラミング手法と見なされるソフトウェア開発の特定のパターンです。
デザインパターン は一般的な問題に対する一般的なアプローチであり、一般的に優れた開発プラクティスと考えられていますが、アンチパターンは反対であり、望ましくありません。
たとえば、オブジェクト指向プログラミングでは、ソフトウェアをオブジェクトと呼ばれる小さな断片に分割するという考え方があります。オブジェクト指向プログラミングのアンチパターンは、 神オブジェクト であり、これは多くの機能を実行しますが、これらはさまざまなオブジェクトに適切に分離されます。
例えば：
class GodObject {
function PerformInitialization() {}
function ReadFromFile() {}
function WriteToFile() {}
function DisplayToScreen() {}
function PerformCalculation() {}
function ValidateInput() {}
// and so on... //
}
上記の例には、everythingを行うオブジェクトがあります。オブジェクト指向プログラミングでは、さまざまなオブジェクトに対して明確に定義された責任を持ち、コードの結合を抑え、最終的に保守性を高めることが望ましいでしょう。
class FileInputOutput {
function ReadFromFile() {}
function WriteToFile() {}
}
class UserInputOutput {
function DisplayToScreen() {}
function ValidateInput() {}
}
class Logic {
function PerformInitialization() {}
function PerformCalculation() {}
}
一番下の行は、よく使用されるパターン（ デザインパターン ）でソフトウェアを開発する良い方法がありますが、問題につながる可能性のあるソフトウェアを開発および実装する方法もあります。悪いソフトウェア開発プラクティスと見なされるパターンはアンチパターンです。
アンチパターンについて耳にするたびに、別の言葉を思い出します。デザインの匂い。
「デザインのにおいは、基本的なデザイン原則の違反を示し、デザインの品質に悪影響を与えるデザインの特定の構造です。」（「ソフトウェアデザインの匂いのリファクタリング：技術的負債の管理」から）
設計原則に違反することに基づいて分類された多くの設計臭があります。
抽象化の匂い
Missing Abstraction：この臭いは、クラスまたはインターフェースを作成する代わりに、データの塊またはエンコードされた文字列が使用されるときに発生します。
Imperative Abstraction：この匂いは、操作がクラスに変換されるときに発生します。
不完全な抽象化：この匂いは、抽象化が補完的または相互に関連するメソッドを完全にサポートしていない場合に発生します。
多面的な抽象化：この匂いは、抽象化に複数の責任が割り当てられている場合に発生します。
不要な抽象化：この匂いは、実際に必要ではない（したがって回避できた）抽象化がソフトウェア設計に導入されたときに発生します。
Unutilized Abstraction：この匂いは、抽象化が未使用のままである場合に発生します（直接使用されていないか、到達できません）。
重複した抽象化：この匂いは、2つ以上の抽象化が同一の名前または同一の実装、またはその両方を持つ場合に発生します。
カプセル化の匂い
不完全なカプセル化：この匂いは、抽象化の1つまたは複数のメンバーの宣言されたアクセシビリティが実際に必要とされるよりも寛容である場合に発生します。
Leaky Encapsulation：この臭いは、パブリックインターフェイスを介して抽象化が実装の詳細を「公開」または「リーク」するときに発生します。
Missing Encapsulation：この匂いは、実装のバリエーションが抽象化または階層内にカプセル化されていない場合に発生します。
Unexploited Encapsulation：クライアントコードが型のバリエーションを利用する代わりに、明示的な型チェック（オブジェクトの型をチェックするif-elseまたはswitchステートメントのチェーンを使用）を使用する場合に発生しますすでに階層内にカプセル化されています。
モジュール化の匂い
Broken Modularization：この臭いは、理想的には単一の抽象化にローカライズされるはずだったデータやメソッドが分離され、複数の抽象化にまたがって広がるときに発生します。
不十分なモジュール化：この臭いは、完全に分解されていない抽象化が存在する場合に発生し、さらに分解するとそのサイズ、実装の複雑さ、またはその両方を減らすことができます。
循環依存のモジュール化：この匂いは、2つ以上の抽象化が互いに直接または間接的に依存している場合に発生します（抽象化間の緊密な結合を作成します）。
Hub-Like Modularization：この匂いは、抽象化に他の多数の抽象化との依存関係（着信と発信の両方）がある場合に発生します。
階層の匂い
Missing Hierarchy：この臭いは、コードセグメントが条件付きロジック（通常は「タグ付きタイプ」と組み合わせて）を使用して、階層を作成して使用できる動作のバリエーションを明示的に管理するときに発生しますそれらのバリエーションをカプセル化します。
不必要な階層：この臭いは、継承階層全体が不要なときに発生し、特定の設計コンテキストに継承が不必要に適用されたことを示します。
Unfactored Hierarchy：この臭いは、階層内の型に不必要な重複がある場合に発生します。
Wide Hierarchy：この臭いは、継承階層が「大きすぎる」場合に発生し、中間型が欠落している可能性があることを示します。
投機的階層：この臭いは、階層内の1つ以上のタイプが投機的に提供された場合に発生します（つまり、実際の要件ではなく、想像上のニーズに基づいています）。
Deep Hierarchy：この臭いは、継承階層が「過度に」深い場合に発生します。
Rebellious Hierarchy：この匂いは、サブタイプがそのスーパータイプによって提供されるメソッドを拒否したときに発生します。
Broken Hierarchy：この匂いは、スーパータイプとそのサブタイプが概念的に「IS-A」関係を共有しない場合に発生し、代替性が壊れます。
マルチパス階層：この匂いは、サブタイプがスーパータイプから直接および間接的に継承し、階層内の不要な継承パスにつながる場合に発生します。
循環階層：この匂いは、階層のスーパータイプがそのサブタイプのいずれかに依存している場合に発生します。
上記の定義と分類は 「ソフトウェア設計のリファクタリング：技術的負債の管理 」で説明されています。より関連性の高いリソースがいくつか見つかりました here 。
パターンは、あるクラスの問題を解決する方法のアイデアです。アンチパターンは、そのアイデアを実装するとデザインが悪くなるため、それを解決しない方法のアイデアです。
例：「パターン」はコードの再利用に関数を使用することであり、「アンチパターン」はコピーと貼り付けを使用することです。どちらも同じ問題を解決しますが、関数を使用すると、通常、コピーアンドペーストよりも読みやすく保守しやすいコードになります。
アンチパターンは、問題を解決しない方法です。しかし、それだけではありません。これは、問題を解決しようとして頻繁に見られる方法でもあります。
AntiPatternsを本当に勉強したい場合は、本AntiPatterns（ISBN-13：978-0471197133）を入手してください。
その中で、「AntiPatternは、明らかに否定的な結果を生む問題に対して一般的に発生する解決策を記述する文学形式です」と定義しています。
そのため、1つのアプリケーション、1つの会社、または1人のプログラマーに限定された、悪いプログラミング手法でありながら一般的な手法ではない場合、AntiPattern定義の「パターン」部分を満たしません。
混乱させる一般的な方法。たとえば、god/kitchensinkクラスのように（すべてを行います）。
anti-patternはdesign patternの補完です。アンチパターンは、特定の状況で使用すべきではないテンプレートソリューションです。
デザインパターンの場合と同様に、アンチパターンもテンプレートであり、特定の問題を解決するための反復可能な方法ですが、最適ではなく非効率的な方法です。
興味深いことに、問題を解決する特定の方法は、パターンとアンチパターンの両方になります。シングルトンはこの代表的な例です。それは両方の文献に登場します。
今日、ソフトウェアエンジニアリングの研究者と実践者は、しばしば「アンチパターン」と「匂い」という用語を同じ意味で使用しています。ただし、概念的には同じではありません。ウィキペディアのアンチパターンのエントリには、アンチパターンが少なくとも2つの要因によって、悪い習慣や悪いアイデアとは異なることが記載されています。アンチパターンは
「一般的に使用されるプロセス、構造、または行動のパターンは、最初は問題に対する適切かつ効果的な対応であるように見えますが、通常は有益な結果よりも悪い結果をもたらします。」
明らかに、パターンとしてアンチパターンが選択されているという信念でアンチパターンが選択されていることを示していますが、メリットよりも多くの負債をもたらします。一方、臭いは、単にソフトウェアシステムの品質に悪影響を及ぼす悪い習慣です。たとえば、Singletonはアンチパターンであり、Godクラス（またはInsufficient Modularization）はデザインの匂いです。
アンチパターンは、人々が間違った方法でプログラムする傾向がある一般的な方法、または少なくともそれほど良くない方法です。
与えられたソフトウェア開発環境に良いことよりも害を及ぼす設計パターンは、アンチパターンと見なされます。
いくつかのアンチパターンは明らかですが、いくつかはそうではありません。たとえば、シングルトンは、多くの人が古き良きデザインパターンを考慮しているにもかかわらず、そうでないものもいます。
質問を確認できます シングルトンの何がそんなに悪いのですか？ さまざまな意見をよりよく理解するために。
アルゴリズムのように、ブルートフォースを使用してソリューションを実現できますが、状況が複雑になった場合は多くを支払う必要があります。