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

モデルに（EFを使用して）さまざまなエンティティがあるとします（ユーザー、製品、請求書、注文など）。 エンティティが事前に決定されたセットに属しているアプリケーションでエンティティオブジェクトの要約を印刷できるユーザーコントロールを作成しています。この場合、ユーザーと製品の要約を要約できると言います。 要約にはすべてIDと説明しか含まれないため、このための簡単なインターフェースを作成します。 public interface ISummarizableEntity { public string ID { get; } public string Description { get; } } 次に、問題のエンティティについて、このインターフェイスを実装する部分クラスを作成します。 public partial class User : ISummarizableEntity { public string ID { get{ return UserID.ToString(); } } public string Description { get{ return String.Format("{0} {1} is from {2} and is …

9 c#  design-patterns  interfaces  anti-patterns  data-types 

私が読んだ最悪のアンチパターンを読んでいるときに、この投稿のリンクをクリックして、アンチパターンに関するWebサイトにアクセスしました。 そして、http：//sourcemaking.com/antipatterns/functional-decompositionのページは私に不思議に思いました。 このアンチパターンはどれほどひどいですか、それともアンチパターンですか？今日私はほとんどOOPプログラミングを行っていますが、Javaのような純粋なOOPのすべての言語や、それらがもたらす設計慣行にもまだ気が進まないためです。コードを書いている間も、関数型プログラミングにはいくつかの特徴があります。 そして、これは質問を持ち出しました、私はOOP + Functionalスタイルに固執することによって間違っていますか、それとも業界では一般的であり、実際にはそれほど悪いことではありませんか？ 私が経験から知っていることは、OOP + Functionalスタイルは純粋なOOP開発者と完全には互換性がないということです。しかし、同時に、OOP開発者はOOP +機能開発に問題を抱えていますが、反対意見は、OOPソリューションは非常に頻繁に設計されすぎて使用が困難であり、私の経験から、少しも簡単ではなく、実際には非常に深刻なバグを隠すためにいくつかの盲点を導入しました。 したがって、これらのトピックについて同僚と話し合ったとしても、どの方法も実際には完璧ではないという結論に達しました。そして、私はまだ質問に答えられていません。 OOP問題は、同じスレッド内の別の投稿からのリンクによっても強化されました。リンクは、JavaスタイルのOOP http://chaosinmotion.com/blog/?p=622にあります。 では、関数型プログラミングとOOPを混合することに対する一般的な態度はどのようなものでしょうか。そして、開発者が達成するために努力すべきバランスは何ですか？

9 object-oriented  functional-programming  anti-patterns 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 6年前休業。 ロックされています。この質問とトピックへの回答はロックされています。質問はトピックから外れていますが、歴史的に重要です。現在、新しい回答や相互作用を受け入れていません。 プログラマーとしてのキャリアで出会った最悪のアンチパターンは何ですか？ 私はJavaにほとんど関わっていますが、おそらく言語に依存していません。 最悪なのは、メインのアンチパターンと呼んでいるものだと思います。これは、すべてのロジックを含む単一の非常に大きなクラス（場合によっては、一対の小さなクラスを伴う）で構成されるプログラムを意味します。通常、すべてのビジネスロジックが含まれる大きなループがあり、時には数万行のコードが含まれます。

9 language-agnostic  anti-patterns 

私が以下を持っているとしましょう： package me.my.pkg; public interface Something { /* ... couple of methods go here ... */ } そして： package me.my; import me.my.pkg.Something; public class SomeClass implements Something { /* ... implementation of Something goes here ... */ /* ... some more method implementations go here too ... */ } つまり、インターフェースを実装するクラスは、実装するインターフェースよりもパッケージ階層のルートの近くにありますが、どちらも同じパッケージ階層に属しています。 …

9 java  api-design  patterns-and-practices  anti-patterns 

私は通常、次の方法でアプリケーションを設計していることに気づきました。 必要なサブシステムのインターフェースを含む1つのDLL。たとえば、Company.Framework.Persistence.dll。 上記のサブシステムの各戦略（または実装）ごとに1つの新しいDLL 。例えば： Company.Framework.Persistence.MSSQL.dll Company.Framework.Persistence.MySQL.dll Company.Framework.Persistence.FileSystem.dll これにより、多くのプロジェクトで非常に大きなソリューションが得られますが、一方で、消費者は自分のニーズに適したDLLを選択する機会が与えられます。 と呼ばれる単一のDLLがある場合Company.Framework.Persistence.dll、消費者は彼が決して使用しない可能性がある多くの戦略をロードする必要があります。DLLをモジュール化すると、この問題を解決できます。 これは良い習慣ですか？この設計には欠点がありますか？

8 design  design-patterns  .net  project-management  anti-patterns 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 次のように、データがHashtable / Dictionary / Associative-Arrayのような構造で格納/交換されるコードを使用します { 'alpha': None, 'bravo': '', # 'charlie' is not given } どのフィールドが「指定」されているか、およびNone / Null / Nilまたは空の文字列として指定できる場合は、標準化はあまりありません。その結果、コードにはlike likeチェックif hasattr(obj, 'alpha')やデフォルトのフォールバックが散らばっています。 この種類の（imho）アンチパターンに名前や俗語はありますか？ 更新： まだ名前がないようですので、是非教えてください。現在、私たちはこれらを持っています： Incorporeal Horde（psrへのクレジット）

8 architecture  anti-patterns