タグ付けされた質問 「anti-patterns」

23個のインターフェイスを実装するクラスを持つことは、おそらくコードの匂いやアンチパターンであると考えるでしょう。それが本当にアンチパターンである場合、あなたはそれを何と呼びますか？それとも、単に単一責任の原則に従っていないだけですか？

28 object-oriented  anti-patterns  solid 

すべてのプログラミングプロジェクトについて、過去のプログラミング経験のあるマネージャーは、プロジェクトのデザインパターンを推奨するときに輝かそうとします。理にかなっている場合、またはスケーラブルなソリューションが必要な場合、デザインパターンが好きです。たとえば、プロキシ、オブザーバー、コマンドパターンを積極的に使用してきましたが、毎日そうしています。しかし、オブジェクトを作成する方法が1つしかない場合、Factoryは将来的にすべてを簡単にする可能性がありますが、コードを複雑にし、純粋なオーバーヘッドであるため、Factoryパターンを使用することを本当にためらっています。 だから、私の質問は私の将来のキャリアと、ランダムなパターン名を投げるマネージャータイプに対する私の答えです： どのデザインパターンを使用しましたか？最悪の設計パターンはどれですか、それらが理にかなっている単一の状況を除いて考慮する必要があるものです（読んでください：どの設計パターンが非常に狭く定義されています）？（アマゾンの全体的な良い製品のネガティブなレビューを探して、デザインパターンを使用する際に最もバグを起こした人々を探しているようです。）そして、ここでアンチパターンについてではなく、通常と考えられるパターンについて話しています「良い」パターン。 編集：一部の人が答えたように、問題はほとんどの場合、パターンが「悪い」のではなく「間違って使用されている」ことです。パターンを知っていれば、それはしばしば誤用されるか、使用するのが難しい場合でも、答えとして当てはまります。

28 bad-code  anti-patterns  patterns-and-practices  design-patterns 

当店では、アジャイルであるよう努めています。そして、私たちは大きな進歩を遂げていると思います。そうは言っても、私たちの何人かは、「障害駆動型開発」と呼んでいるパターンを発見しました。 障害駆動型開発は基本的に、バグ/機能が受け入れ基準を備えたタスクやストーリーではなく、欠陥追跡ソフトウェアに入力された欠陥によって導かれるアジャイルなリリース/反復サイクルとして記述できます。 私たちのチームには、顧客からの受け入れ基準の取得に努める優れたプロジェクトマネージャーがいますが、常に可能であるとは限りません。私の開発委員長から、これは顧客が自分が望むものを正確に知らないか、顧客の本社の2つの異なる「キャンプ」がストーリーの実装方法と対立するためです。キャンプAは、機能Xがこのように機能することを大まかに指示し、キャンプBはそのように機能しないために失敗します。したがって、「FDD」という用語。プロセスは「失敗」によって駆動されます。 これは私の質問につながります：他の誰かがこれに遭遇しましたか？もしそうなら、それを扱うためのヒント/提案はありますか？ もちろん、キャンプAとBが事前に同意するように試みましたが、これは必ずしもそうではないことを誰もが知っています。 ありがとう

28 agile  anti-patterns 

シングルトンパターンに関するさまざまな意見を読みました。一部の人は、すべてのコストで回避する必要があると主張し、他の人は、特定の状況で役立つ可能性があると主張しています。 シングルトンを使用する1つの状況は、特定のクラスAのオブジェクトを作成するためにファクトリー（たとえば、タイプFのオブジェクトf）が必要な場合です。ファクトリーは、いくつかの構成パラメーターを使用して一度作成され、その後、タイプAがインスタンス化されます。したがって、Aをインスタンス化するコードのすべての部分は、シングルトンfをフェッチし、新しいインスタンスを作成します。たとえば、 F& f = F::instance(); boost::shared_ptr<A> a = f.createA(); 一般的な私のシナリオは 最適化の理由（複数のファクトリオブジェクトは必要ありません）または共通の状態を共有するためにクラスのインスタンスが1つだけ必要です（たとえば、ファクトリはAのインスタンスをいくつ作成できるかを知っています） コードのさまざまな場所でFのこのインスタンスfにアクセスする方法が必要です。 このパターンが良いか悪いかについての議論には興味がありませんが、シングルトンの使用を避けたい場合、他にどのようなパターンを使用できますか？ 私が持っていたアイデアは、（1）レジストリからファクトリオブジェクトを取得するか、（2）プログラムの起動中のある時点でファクトリを作成し、パラメータとしてファクトリを渡すことでした。 ソリューション（1）では、レジストリ自体がシングルトンであるため、シングルトンを使用しないという問題を工場からレジストリに移行しました。 （2）の場合、ファクトリオブジェクトの元となる初期ソース（オブジェクト）が必要なので、別のシングルトン（ファクトリインスタンスを提供するオブジェクト）に再びフォールバックするのではないかと心配しています。このシングルトンのチェーンをたどると、他のすべてのシングルトン を直接または間接的に管理する1つのシングルトン（アプリケーション全体）に問題を減らすことができます。 この最後のオプション（他のすべての一意のオブジェクトを作成し、他のすべてのシングルトンを適切な場所に注入する1つの初期シングルトンを使用）は、許容できる解決策でしょうか？これは、シングルトンを使用しないことを勧めるときに暗黙的に提案される解決策ですか、それとも他の解決策は何ですか？ 編集 私の質問の要点は一部の人によって誤解されていると思うので、ここにいくつかの情報があります。ここで説明するように、シングルトンという言葉 は、（a）単一インスタンスオブジェクトを持つクラスと、（b）そのようなオブジェクトの作成とアクセスに使用されるデザインパターンを示すことができます。 物事を明確にするために、（a）には ユニークオブジェクト、（b）にはシングルトンパターンという用語を使用します。だから、私はシングルトンパターンと依存性注入が何であるかを知っています（最近、私は作業中のコードからシングルトンパターンのインスタンスを削除するためにDIを多用しています）。 私のポイントは、オブジェクトグラフ全体がmainメソッドのスタックにある単一のオブジェクトからインスタンス化されない限り、シングルトンパターンを通じていくつかの一意のオブジェクトに常にアクセスする必要があるということです。 私の質問は、完全なオブジェクトグラフの作成と配線をメインメソッドに依存させること（たとえば、パターン自体を使用しない強力なDIフレームワークを使用すること）が、シングルトンパターンを使用しない唯一のソリューションかどうか です。

27 design-patterns  programming-practices  anti-patterns  singleton 

これは、繰り返し繰り返されている規則の1つであり、私を困惑させます。 ヌルは悪であり、可能な限り避けるべきです。 しかし、しかし-私の素朴さから、私に悲鳴を上げさせてください-時には価値が意味なく欠けていることがあります！ 私が今取り組んでいるこのアンチパターンに乗った恐ろしいコードから来る例でこれを聞かせてください。これは、中核となるマルチプレイヤーウェブターンベースのゲームであり、両方のプレイヤーのターンが同時に実行されます（ポケモンのように、チェスとは逆に）。 各ターンの後に、サーバーは更新のリストをクライアント側のJSコードにブロードキャストします。更新クラス： public class GameUpdate { public Player player; // other stuff } このクラスはJSONにシリアル化され、接続されているプレーヤーに送信されます。 ほとんどのアップデートには当然プレイヤーが関連付けられています-結局のところ、どのプレイヤーがこのターンにどのプレイヤーを動かしたかを知る必要があります。ただし、一部の更新プログラムでは、意味のあるPlayerを関連付けることができません。例：アクションなしのターン制限を超えたため、ゲームは強制的に結び付けられました。このような更新では、プレーヤーを無効にすることは有意義だと思います。 もちろん、継承を利用することでこのコードを「修正」できます。 public class GameUpdate { // stuff } public class GamePlayerUpdate : GameUpdate { public Player player; // other stuff } ただし、次の2つの理由から、これがどのように改善されるかはわかりません。 JSコードは、定義されたプロパティとしてPlayerのないオブジェクトを受け取るだけです。これは、値が存在するかどうかを確認する必要があるため、nullの場合と同じです。 別のnull可能フィールドをGameUpdateクラスに追加する場合、この設計を続行するには多重継承を使用できる必要がありますが、MIはそれ自体が悪であり（経験豊富なプログラマーによると）、さらに重要なことには、C＃はそうではありません持っているので使用できません。 このコードのこの部分は、経験豊富で優秀なプログラマーが恐怖で叫ぶことになる非常に多くのコードの1つであるという感想があります。同時に、この場所でこのヌルがどのように何かを傷つけているか、代わりに何をすべきかを見ることができません。 この問題について説明してもらえますか？

26 anti-patterns  null 

プログラマーが意味をなさない領域に物事をまとめる傾向があるコードベースがあります。たとえば、エラーログがある場合、次の方法でログインできます。 ErrorLog.Log(ex, "friendly message"); 彼は、まったく同じタスクを達成するために他のさまざまな手段を追加しました。例えば SomeClass.Log(ex, "friendly message"); 単に向きを変えて最初のメソッドを呼び出します。これにより、利点が追加されずに複雑さが増します。これを説明するアンチパターンはありますか？

26 design-patterns  anti-patterns 

「異常終了」を表すためにを使用することを推奨するexit(-1)、インターネット上の多くのレガシーソフトウェアや悪いチュートリアルに見られreturn -1ます。問題は、少なくともPOSIXでは-1、有効なステータスコードではなく、有効なステータスコードです。man 3 exitはのexit()値をstatus & 0377親に返すことを示しています。つまり、に-1なり255ます。非POSIXシステムでEXIT_FAILUREは、移植性のために推奨されます。しかし、「-1は異常終了を意味する」と「EXIT_FAILUREは1以外の可能性があります」とは表示されません。 これを永続化するStackOverflowの質問の例を次に示します。ソフトウェア「unrealircd」も、プログラムのexit(-1)終了に使用するプログラムの例です。実際には、これにより、とのインターフェースが難しくなりますsystemd。 このアンチパターンはどこから来たのですか？あるコンテキストで有効ですか？

22 programming-practices  c  history  anti-patterns 

コードの大部分を変更する必要があることがわかったときは、それが間違っているか、他の理由で必要となる主要なアーキテクチャの変更に適応する必要があるため、これは私が通常行うことです： 変更が必要と思われるすべてのコードをコメント化します。コメントアウトされたコードは、TODOリストの一種として扱います。 コメントアウトされたコードを徐々に確認し、このコードの一部のコメントを外すか、必要に応じてコピーアンドペーストして必要に応じて編集するか、このコードの一部を最初から書き直して、コメントアウトされたコードを参照します。コメントアウトされたコードの一部が完了したと思うたびに、それを削除します。 コードがコメントアウトされなくなるまでこれを続けます。 私は主に、私が単独で開発している個人プロジェクトでこれを行っていることに注意する必要があります。 しかし、私はこれをやめるべきだと言われました。代わりに、コメントアウトされたコードを残すのではなく、古いコードを見るために古いコミットを参照してgitを使い始めるべきだと言われました。私が言われた： コードをコメントアウトするのは悪い習慣であり、一掃する必要があります。経験がないため、それを理解できません。数年後に、コードをコメントアウトするのが好きな別の人のコードを見つけた場合、自分でこの人を非難するでしょう。コメントアウトされたコードを見るたびに、私はそれを見ずにその全体を削除します。通常、そのようなコードは完全に価値がないからです。小規模な個人プロジェクトでは、コードをコメントアウトすることのマイナス面を確実に見落とすでしょう。しかし、あなたが仕事を見つけて、この習慣をそこに保つならば、それは残念です。 私が今見逃していることの、私がやっていることのこれらの欠点は何ですか？ 私は、過去のコードを見るためにgitを使用することだけに熱心ではないと言わなければなりません。私が言ったように、私はコードをコメントアウトすることを一種のtodoリストとして扱います。gitは、コードが以前どのように表示されていたかを示しますが、コードのどの部分がまだレビューが必要で、どの部分がすでに実行されているかを明確に示すことはできません。コードの一部を見逃し、バグを導入する恐れがあります。 完全を期すために、引用している人は経験豊富な開発者であり、ボブおじさんの「クリーンコード」のファンであると付け加えるべきだと思います。

21 anti-patterns  comments 

私はしばしば、Javaのヘルパークラスまたはutilクラスまたはあらゆる種類の言語に直面しています。それで、私はこれがアンチパターンの一種であり、この種のクラスの存在はソフトウェアの設計とアーキテクチャに欠けているだけかどうかを自問していた。 多くの場合、これらのクラスは、多くのことを行う静的メソッドのみを使用して制限されます。しかし、ほとんどの場合、実際にはコンテキストに依存し、ステートフルです。 私の質問は、そのような種類の静的ヘルパー/ユーティリティクラスについてのあなたの意見は何ですか？利点はもちろんクラス名だけを使用した高速呼び出しであるためです。 そして、これらの種類のクラスの使用を避けるのは、どのような抽象化レベルですか？ 私の意見では、キーワード「static」はクラスの宣言（Java）内でのみ許可され、メソッドでは許可されません。私の意見では、この方法でそれを使用することは、Javaで手続き型パラダイムとオブジェクト指向パラダイムを組み合わせて、キーワードの誤用を回避するための優れた代替手段であると考えられます。 答えによる追加： 最初は、異なるパラダイムを組み合わせたり、マシンまたはvmでコンパイルされたコード内で実行時解釈スクリプト言語を使用したりすることは完全に合法だと思います。 私の経験では、プロジェクトの開発プロセス中に、そのような種類のヘルパーやユーティリティ、または名前が何であれ、コードベースの忘れられた隅々で成長し、使用されています。そして、リファクタリングを行う時間や設計をもう一度考える時間がないため、時間の経過とともにそれをさらに悪化させます。 staticJavaから削除する必要があると思います。特に今では、さらに洗練された関数型言語要素を使用することができます。

19 design-patterns  anti-patterns  static 

私はよくオンラインで質問を探しますが、多くのソリューションには辞書が含まれています。しかし、それらを実装しようとするたびに、コードにこの恐ろしい悪臭が入ります。たとえば、値を使用するたびに： int x; if (dict.TryGetValue("key", out x)) { DoSomethingWith(x); } これは、基本的に次のことを行う4行のコードです。 DoSomethingWith(dict["key"]) outキーワードを使用すると、関数のパラメーターが変化するため、アンチパターンであると聞きました。 また、キーと値を反転させる「逆」辞書が必要になることがよくあります。 同様に、辞書の項目を繰り返し処理して、キーまたは値をリストなどに変換して、これを改善したいと思うことがよくあります。 辞書を使用するより良い、よりエレガントな方法はほとんど常にあるように感じますが、私は途方に暮れています。

19 c#  anti-patterns  code-smell  dictionary  out-parameters 

私たちのウェブアプリケーションはを使用しExceptionMapperていくつかの例外をにマップしていますResponse。次のように、新しい例外をスローする前に例外メッセージを記録します。 catch (SomeException ex) { LOG.error(ex.getMessage()); throw new MyException(ex.getMessage()); } 私たちは同じ例外を再スローしていないので、私の質問は、これがLog and Throwアンチパターンと見なされるかどうかです。したがって、同様の場所でロギングを削除し、ExceptionMapper次のようにいくつかのクラスに移動する方が良いでしょう： @Provider public class MyExceptionMapper implements ExceptionMapper<MyException> { // bla bla @Override public Response toResponse(final MyException ex) { LOG.error(ex.getMessage()); return Response.status(400).entity("something").build(); } }

18 java  anti-patterns 

今日のTDWTFの記事は、著者からの告白から始まります。 For-Caseアンチパターンが何であるかは、比較的最近まで、アンチパターンとして非難する記事が相次いだときまで知りませんでした。おそらくある時点で使用したと思いますが、名前でそれを知らなかったのです。これは、一般にforループ、caseステートメント、解決される問題、または3つすべての組み合わせの誤解を意味する教科書のアンチパターンと考えられています。 それから、読者は、当然のことながら、For-Caseアンチパターンが何であるかを知っているかのように進み、それ以上の説明は必要ありません。 しかし、私はしません！Remyが語る「一連の記事」を見たことはありません。Googleで見つけることができる唯一の重要な参照（Remyの記事以外）は、for-ifアンチパターンに関するRaymond Chenのブログ投稿です。 。しかし、彼は「for-case anti-pattern」も定義していません。 これらの人々が話しているこの「For-Caseアンチパターン」とは何ですか？

17 anti-patterns 

私はこの表現とパターンを昔に教えられました。確かに、その名前は、水を汲み出す前に水で満たす必要があった古いポンプに由来しますが、誰が気にしますか？ここでコードについて話しています。 いくつかの本当に良い例と、パターンが達成することの説明は歓迎されます。このパターンは今日どのように考えられていますか？ プライミングは時々、欠陥のあるループを動作させることができますが、DRYを犠牲にします。したがって、より良い設計への道の途中で一時停止することがあります。これはアンチパターンと見なされますか？代替手段はありますか？

17 design-patterns  anti-patterns  loops 

Martin FowlerのRefactoring bookで一般的なコードのにおいについて読んでいます。その文脈で、私はコードベースで見ているパターンについて疑問に思っていました、そしてそれが客観的にそれをアンチパターンと考えることができるかどうか。 パターンは、オブジェクトが1つ以上のメソッドへの引数として渡されるものであり、それらはすべてオブジェクトの状態を変更しますが、いずれもオブジェクトを返しません。そのため、（この場合は）C＃/。NETの参照によるパスに依存しています。 var something = new Thing(); // ... Foo(something); int result = Bar(something, 42); Baz(something); （特にメソッドに適切な名前が付けられていない場合）そのようなメソッドを調べて、オブジェクトの状態が変化したかどうかを理解する必要があることがわかりました。複数レベルの呼び出しスタックを追跡する必要があるため、コードの理解がより複雑になります。 このようなコードを改善して、新しい状態の別の（クローンされた）オブジェクト、または呼び出しサイトでオブジェクトを変更するために必要なものを返すことを提案したいと思います。 var something1 = new Thing(); // ... // Let's return a new instance of Thing var something2 = Foo(something1); // Let's use out param to 'return' other info about the …

17 code-smell  anti-patterns  parameters 

ユニットテストを行うとき、どのくらいの量のデータをフィードし、テスト対象のユニットから戻ってくるのかを議論することがよくあるので、実際のテストファイルに含める必要があります。 私が常に苦労しているトレードオフは： テストの大部分（コードボリューム内）が入力データと出力データで構成されている場合、実際にテストを読み取ることは困難に思えますが、実際の入出力を簡単に確認できます。 ファイルからテストデータを読み込むと、可能なデータ入力のバリエーションを簡単にテストでき、テストデータを複数のテストに簡単に再利用できますが、入力が正確に何であるかを確認するには、ソースコードを残しておく必要があります。 これらのいずれかがアンチパターンですか？

16 unit-testing  anti-patterns  unit-test-data