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

https://stackoverflow.com/questions/980601

13-09-2019
|

質問

パターンとアンチパターンについて勉強しています。パターンについては明確に理解していますが、アンチパターンはわかりません。ウェブやウィキペディアの定義は私を大いに混乱させます。

アンチパターンとは何かを簡単な言葉で説明してくれる人はいますか?目的は何ですか?彼らは何をしますか？それは悪いことですか、それとも良いことですか?

解決

となっている一般的な問題に対する一般的なアプローチですのデザインパターンとは対照的に正式に一般的にアンチパターンが反対であり、望ましくない、良い開発プラクティスと考えられております。

例えば、オブジェクト指向プログラミングでは、アイデアは、オブジェクトと呼ばれる小片にソフトウェアを分離することです。オブジェクト指向プログラミングにおけるアンチパターンは、希望の機能の多くを実行神オブジェクトのrel="noreferrer">の

例

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」関係を共有せず、その結果代替性が損なわれた場合に発生します。

マルチパス階層: この臭いは、サブタイプがスーパータイプから直接的および間接的に継承し、階層内に不必要な継承パスが生じる場合に発生します。

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

上記の定義と分類については、「ソフトウェア設計のリファクタリングは臭い:技術的負債の管理」。さらに関連性の高いリソースがいくつか見つかる可能性がありますここ.

のパターンはいくつかのクラスの問題を解決する方法のアイデアです。アンチパターンは、そのアイデアを実装することは悪いデザインにつながるので、それを解決する方法はないのでしょう。

例：「パターン」は、「アンチパターン」と同じため、コピー＆ペーストを使用することで、コードの再利用のための機能を使用することであろう。どちらも、同じ問題を解決しますが、機能を使用すると、通常のコピー＆ペーストよりも読みやすく、メンテナンス性のコードにつながるます。

アンチパターンは、問題を解決しない方法です。しかしそれはもっとあります：それはまた、頻繁に問題を解決しようとする試みで見ることができる方法です。

。

あなたが本当に本を取得するには、アンチパターンを勉強したい場合は、のアンチパターンの（ISBN-13：978から0471197133）。

その中で、彼らは「アンアンチパターンは明らかに否定的な結果を生成し、この問題に対する一般的に発生する解決策を説明文学形式である。」を定義

だから、それは悪いプログラミングの練習ではなく、一般的なものが制限された一つのアプリケーション、一社の企業または1人のプログラマが、それはアンチパターン定義の「パターン」の部分を満たしていないに。

だ場合

混乱を作るための一般的な方法。例えば、（すべてを行い）神/ kitchensinkクラスと同様ます。

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

ただ、のデザインパターンのと同じように、のアンチパターンのも、テンプレートや特定の問題を解決するための反復可能な方法ですが、非最適と無効で道ます。

パターンとアンチパターンの両方をすることができ、問題を解決する興味深いことに、所与の方法。シングルトンは、この一例です。それは文学の両方のセットに表示されます。

今日、ソフトウェア工学の研究者や実務家は、多くの場合、用語「アンチパターン」と同義的に「臭い」を使用します。しかし、彼らは概念的には同じではありません。アンチパターンのWikipediaのエントリは、アンチパターンは、少なくとも2つの要因によって、悪い習慣や悪い考えは異なっていると述べています。アンチパターンがある。

"一般的に使用される方法、構造または動作のパターンにもかかわらず、その最初に適切かつ効果的な応答であるように見えます問題は、一般的に有益な結果よりも悪い結果を持っています。」

のこれは明らかにアンチパターンは、それが提示される問題の（パターンなど）は良い解決策であるという信念に選択されることを示しています。しかし、それはメリットよりも多くの負債をもたらします。一方の、香りは単に負ソフトウェアシステムの品質に影響を与える悪い習慣です。例えば、シングルトンは、アンチパターンと神クラス（または不十分なモジュール化）が設計臭いである。

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

与えられたソフトウェア開発環境に良いよりも害をやっている任意のデザインパターンは、アンチパターンとみなされるであろう。

いくつかのアンチパターンは明白ですが、いくつかはそうではありません。例えばシングルトンは、多くの人がそれ古き良きデザインパターンを検討していてもないが、他があります。

あなたはより良いにの？シングルトンそんなに悪いとは何か疑問を確認することができますその上に別の意見を理解します。

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow