アンチパターンとは何ですか？

私はパターンとアンチパターンを研究しています。私はパターンについて明確な考えを持っていますが、アンチパターンを取得していません。WebとWikipediaの定義は私を混乱させます。

誰かがアンチパターンとは何かを簡単な言葉で私に説明できますか？目的は何ですか？彼らは何をしますか？それは悪いことですか、それとも良いことですか？

アンチパターンは、ソフトウェア開発における特定のパターンであり、不適切なプログラミング手法と見なされています。

形式化された一般的な問題への一般的なアプローチであり、一般に優れた開発手法と見なされている設計パターンとは対照的に、アンチパターンは反対であり、望ましくありません。

たとえば、オブジェクト指向プログラミングでは、ソフトウェアをオブジェクトと呼ばれる小さな部分に分離するという考え方です。オブジェクト指向プログラミングのアンチパターンは、さまざまなオブジェクトに分離された多くの機能を実行する神オブジェクトです。

例えば：

class GodObject {
    function PerformInitialization() {}
    function ReadFromFile() {}
    function WriteToFile() {}
    function DisplayToScreen() {}
    function PerformCalculation() {}
    function ValidateInput() {}
    // and so on... //
}

上記の例には、すべてを行うオブジェクトがあります。オブジェクト指向プログラミングでは、さまざまなオブジェクトに対して明確に定義された責任を負って、コードの結合を少なくし、最終的には保守しやすくすることが望ましいでしょう。

class FileInputOutput {
    function ReadFromFile() {}
    function WriteToFile() {}
}

class UserInputOutput {
    function DisplayToScreen() {}
    function ValidateInput() {}
}

class Logic {
    function PerformInitialization() {}
    function PerformCalculation() {}
}

肝心な点は、一般的に使用されるパターン（デザインパターン）を使用してソフトウェアを開発する良い方法があることですが、問題を引き起こす可能性があるソフトウェアを開発して実装する方法もあります。悪いソフトウェア開発慣行と見なされるパターンはアンチパターンです。

アンチパターンについて聞いたときはいつでも、私は別の用語を思い出します。デザインのにおい。

「デザインのにおいは、基本的なデザイン原則の違反を示し、デザインの品質に悪影響を与えるデザインの特定の構造です」（「ソフトウェアデザインのにおいのリファクタリング：技術的負債の管理」から）

違反する設計原則に基づいて分類された多くの設計臭があります：

抽象化の匂い

抽象化の欠如：このにおいは、クラスやインターフェースを作成するのではなく、データのまとまりやエンコードされた文字列を使用したときに発生します。

命令型抽象化：このにおいは、操作がクラスに変換されるときに発生します。

不完全な抽象化：このにおいは、抽象化が補完的または相互に関連するメソッドを完全にサポートしていない場合に発生します。

多面的な抽象化：このにおいは、抽象化に複数の責任が割り当てられている場合に発生します。

不必要な抽象化：この臭いは、実際には不要な（したがって回避できたはずの）抽象化がソフトウェア設計に導入されたときに発生します。

未利用の抽象化：この匂いは、抽象化が未使用のままになっている場合に発生します（直接使用されないか、到達できない）。

重複する抽象化：このにおいは、2つ以上の抽象化が同じ名前または同じ実装または両方を持つ場合に発生します。

カプセル化臭

カプセル化の欠陥：このにおいは、抽象化の1つまたは複数のメンバーの宣言されたアクセス可能性が実際に必要な許容度よりも高い場合に発生します。

漏洩カプセル化：このにおいは、抽象がそのパブリックインターフェースを通じて実装の詳細を「公開」または「漏洩」するときに発生します。

カプセル化の欠如：このにおいは、実装のバリエーションが抽象化または階層内にカプセル化されていない場合に発生します。

未利用のカプセル化：この臭いは、クライアントコードが、階層内に既にカプセル化されているタイプのバリエーションを利用する代わりに、明示的なタイプチェック（オブジェクトのタイプをチェックするチェーンif-elseまたはswitchステートメントを使用）を使用する場合に発生します。

モジュール化臭い

壊れたモジュール化：このにおいは、理想的には1つの抽象化にローカライズされているはずのデータやメソッドが分離され、複数の抽象化に分散している場合に発生します。

不十分なモジュール化：このにおいは、完全に分解されていない抽象化が存在し、さらに分解すると、そのサイズ、実装の複雑さ、またはその両方を削減できる場合に発生します。

循環依存のモジュール化：このにおいは、2つ以上の抽象化が直接的または間接的に相互に依存している場合に発生します（抽象化間の密結合を作成します）。

ハブのようなモジュール化：このにおいは、抽象化に他の多数の抽象化との依存関係（着信と発信の両方）がある場合に発生します。

階層のにおい

階層の欠如：このにおいは、コードセグメントが条件付きロジックを使用して（通常は「タグ付けされた型」と組み合わせて）、階層が作成され、それらのバリエーションをカプセル化するために使用された可能性のある動作のバリエーションを明示的に管理するときに発生します。

不要な階層：このにおいは、継承階層全体が不要な場合に発生します。これは、特定のデザインコンテキストに継承が不必要に適用されたことを示します。

分解されていない階層：このにおいは、階層内の型間で不要な重複がある場合に発生します。

ワイド階層：このにおいは、継承階層の幅が「広すぎる」場合に発生し、中間タイプが欠落している可能性があることを示します。

投機的階層：このにおいは、階層内の1つ以上のタイプが投機的に（つまり、実際の要件ではなく想像上のニーズに基づいて）提供されるときに発生します。

深い階層：このにおいは、継承階層が「過度に」深い場合に発生します。

反抗的な階層：このにおいは、サブタイプがそのスーパータイプによって提供されるメソッドを拒否したときに発生します。

階層の破綻：このにおいは、スーパータイプとそのサブタイプが概念的に「IS-A」の関係を共有していないために発生し、その結果、代替可能性が破綻します。

マルチパス階層：このにおいは、サブタイプがスーパータイプから直接または間接に継承され、階層内の不要な継承パスにつながる場合に発生します。

循環階層：このにおいは、階層内のスーパータイプがそのサブタイプのいずれかに依存している場合に発生します。

上記の定義と分類は、「ソフトウェア設計のにおいのためのリファクタリング：技術的負債の管理」で説明されています。さらに関連するリソースがここにあります。

パターンとは、あるクラスの問題を解決する方法のアイデアです。アンチパターンは、そのアイデアを実装すると悪いデザインになるため、それを解決しない方法のアイデアです。

例：「パターン」はコードの再利用のために関数を使用することであり、「アンチパターン」は同じためにコピーと貼り付けを使用することです。どちらも同じ問題を解決しますが、関数を使用すると、通常、コピーして貼り付けるよりも読みやすく、保守しやすいコードになります。

アンチパターンは問題を解決しない方法です。しかし、それだけではありません。これは、問題を解決するために頻繁に見られる方法でもあります。

AntiPatternsを勉強したい場合は、AntiPatterns（ISBN-13：978-0471197133）を入手してください。

その中で、彼らは「AntiPatternは、明らかに否定的な結果を生み出す問題に対して一般的に発生する解決策を説明する文学的形式です」と定義しています。

したがって、それが不適切なプログラミング慣行であるが一般的なものではない場合（1つのアプリケーション、1つの会社、または1つのプログラマーに限定）、AntiPattern定義の「パターン」の部分を満たしていません。

混乱を作る一般的な方法。たとえば、god / kitchensinkクラス（すべてを行う）のように。

興味深いことに、問題を解決する特定の方法は、パターンとアンチパターンの両方になる可能性があります。シングルトンは、この典型的な例です。それは両方の文学のセットに表示されます。

アンチパターンは、の補数であるデザインパターン。アンチパターンは、特定の状況で使用してはならないテンプレートソリューションです。

ちょうどと同じようにデザインパターン、アンチパターンは、テンプレートと、特定の問題を解決するための反復可能な方法が、非最適かつ効果的でない方法でもあります。

今日、ソフトウェアエンジニアリングの研究者と実践者は、しばしば「アンチパターン」と「匂い」という用語を同じ意味で使用しています。ただし、概念的には同じではありません。ウィキペディアのアンチパターンのエントリーには、アンチパターンは悪い習慣や悪いアイデアとは少なくとも2つの要素で異なると記載されています。アンチパターンは

「一般的に使用されるプロセス、構造、またはアクションのパターンは、最初は問題に対する適切かつ効果的な対応であるように見えますが、通常は有益な結果よりも悪い結果をもたらします。」

それは明らかに、提示された問題に対する（パターンとしての）良い解決策であるという信念でアンチパターンが選択されていることを示しています。ただし、利益よりも負債が多くなります。一方、匂いは単にソフトウェアシステムの品質に悪影響を及ぼす悪い習慣です。たとえば、Singletonはアンチパターンで、Godクラス（またはInsufficient Modularization）はデザインの匂いです。

アンチパターンは、人々が間違った方法でプログラムする傾向がある一般的な方法、または少なくともそれほど良くない方法です。

特定のソフトウェア開発環境に害を及ぼす以上の害を及ぼす設計パターンは、アンチパターンと見なされます。

明らかなアンチパターンもあれば、そうでないものもあります。たとえばシングルトンは、古き良きデザインパターンだと多くの人が考えていますが、そうでない人もいます。

あなたは疑問チェックすることができ、シングルトンそんなに悪いです何を？それに関するさまざまな意見をよりよく理解するために。

アルゴリズムの場合と同様に、ブルートフォースを使用してソリューションを実現できますが、状況が複雑になると多くの費用を支払う必要があります。