問題タブ [anti-patterns]

今日のプログラミングで見られる抽象化の逆転の最悪の例は何ですか?

この概念に慣れていない方のために説明すると、抽象化の反転は、高レベルの構造の上に低レベルの構造を実装することです。より正確には、コンストラクト A と B があるとします。B は A の上に実装されていますが、A はどこにも公開されていません。したがって、下位レベルのコンストラクト A が本当に必要な場合は、そもそも B が A に関して実装されている場合、B の上に A を実装することになります。http://en.wikipedia.org/wiki/Abstraction_inversionを参照してください。

私の前の質問のフォローアップとして、次のよう な一般的な境界を組み合わせた関数を持つ：

これは未指定のオブジェクトからキャストできないため、これらのインターフェイスを実際に実装するオブジェクトについての知識が必要です。渡すオブジェクト引数の特定のタイプを知る必要がdoStuff(T a)あることは、デメテルの法則に違反しているように思えます。

この関数は、実際のクラスを知る必要性を指定していません (さまざまなクラスが存在する可能性があります)。このクラスを知ると、コード ベースの依存関係が増加するため、知りたくありません。

これらの境界を使用するのはアンチ パターンですか? もしそうなら、どのようにそれを避けるべきですか？

ケース シナリオには、オブジェクトが永続的であることを指定する 1 つのインターフェイスと、関連するエンティティを持つ別の指定されたオブジェクトが含まれます。この場合のdoStuff(T a)関数は、永続化されたときに関連エンティティを永続化しました。ただし、非永続エンティティも関連エンティティを持つことができますが、doStuff(T a)関数によって処理されるべきではありません

アンチパターン: 実際のアンチパターンを単純な悪い習慣、悪い習慣、または悪い考えと正式に区別するには、少なくとも 2 つの重要な要素が存在する必要があります。

• 最初は有益に見えるが、最終的には有益な結果よりも悪い結果をもたらす行動、プロセス、または構造の繰り返しパターン、および
• 明確に文書化され、実際の実践で証明され、再現可能なリファクタリングされたソリューション。

「実際に」何度も目にした TDD アンチパターンに投票してください。
James Carr によるブログ投稿と testdrivendevelopment yahoogroup に関する関連ディスカッション

「名前のない」ものを見つけたら..それらも投稿してください。アンチパターンごとに 1 つの投稿を行って、投票が何かにカウントされるようにしてください。

私の既得権益は、上位 n 個のサブセットを見つけて、近い将来のランチボックス ミーティングでそれらについて議論できるようにすることです。

Subversion を使用すると、 externalsを使用して他のリポジトリの作業コピーを埋め込むことができ、プロジェクト内のサードパーティ ライブラリ ソフトウェアのバージョン管理が容易になります。

これらはライブラリの再利用とベンダー ソフトウェアのバージョン管理には理想的ですが、批判がないわけではありません。

Subversion の外部 (または他のツールで同様のもの) を使用しないでください。これらはアンチパターンであるため、不要です。

外部の使用に隠れたリスクはありますか? それらがアンチパターンと見なされる理由を説明してください。

リレーショナル データベースを扱っている私たち全員が、SQL が他とは異なることを知っています (または学んでいます)。望ましい結果を引き出し、それを効率的に行うには、なじみのないパラダイムを学習し、最もよく知られているプログラミング パターンのいくつかがここでは機能しないことを発見することを部分的に特徴とする、退屈なプロセスが必要です。あなたが見た (またはあなた自身がコミットした) 一般的なアンチパターンは何ですか?

私が取り組んでいたクラスの別のセクションにあるコードをリファクタリングしたのは、一連のネストされた条件演算子 (?:) であり、非常に単純な switch ステートメント (C#) によって非常に明確になったためです。

より明確にするために、直接取り組んでいるものではないコードに触れるのはいつですか?

私は最近 Java で働き始め、すべてのゲッターとセッターのワイルドでクレイジーな世界を紹介されました。最初は嫌でしたが、すぐに慣れました。慣れすぎ。

私は最近、クラスの設計について考えることに多くの時間を費やしています。私がやろうとしていることの 1 つは、すべてに対してゲッターとセッターを実行するという罠を回避することです。ただし、私が行う作業の多くは、主にデータ コンテナーであるエンティティを使用するものであり、これらの場合にゲッターとセッターが実際に不適切であるかどうかはわかりません。

パブリック プロパティを使用した簡単な例を次に示します。

プライベート プロパティを使用し、ゲッターとセッターを使用する簡単な例を次に示します。

これらの例では、nameとdescriptionフィールドの両方を変更できる必要があります。

nameゲッター/セッターの例はより明確で、実装の詳細を隠しているように感じdescriptionます。必要に応じて、後でセットで検証することもできます。

ゲッターとセッターが悪であり、アンチパターンであるという議論をいくつか読みましたが、この状況には当てはまらないように感じます。

まだ検討していないオプションがいくつかあるかもしれません。提案をお待ちしています！

DateLastUpdated のような名前のデータベース テーブルの列を参照する質問が浮かんでいるのをよく見かけます。理解できません。

私が今まで見た唯一のコンパニオン フィールドは、LastUpdateUserId などです。更新が行われた理由についての指標はありません。または更新が何であったかさえ。

その上、このフィールドはトリガー内から書き込まれることがあり、使用できるコンテキストがさらに少なくなります。

確かに、監査証跡にはほど遠いものです。だから正当化できない。また、ログなどのどこかに監査証跡がある場合、このフィールドは冗長になります。

私は何が欠けていますか？このパターンが人気の理由は？

私は現在、「パフォーマンス上の理由」のために、お粗末なテストや保守が不可能なコードを変更することに恐怖を感じているクライアントのために働いています。多くの誤解が蔓延していることは明らかであり、その理由は理解されておらず、単に盲目的な信念に従っているだけです。

私が遭遇したそのようなアンチパターンの 1 つは、できるだけ多くのクラスを封印された内部としてマークする必要があることです...

*再編集: すべてを封印された内部 (C#) としてマークするのは時期尚早の最適化だと思います.*

人々が認識している、または遭遇する可能性のある他のパフォーマンスのアンチパターンにはどのようなものがあるのだろうか?