問題タブ [anti-patterns]

会社の本番環境でこれまでに見た中で最も邪悪または危険なコードの断片は何ですか? 故意に悪意があり悪意があると思われる製品コードに遭遇したことがないので、他の人が何を発見したか非常に興味があります。

私が今まで見た中で最も危険なコードは、コアの実稼働データベース サーバーから 2 つのリンク サーバーにあるストアド プロシージャでした。ストアド プロシージャは、任意の NVARCHAR(8000) パラメータを受け入れ、ダブル ジャンプ sp_executeSQL コマンドを介して、対象の運用サーバーでパラメータを実行しました。つまり、sp_executeSQL コマンドは、2 つのリンクされたサーバーをジャンプするために別の sp_executeSQL コマンドを実行しました。ああ、リンクされたサーバー アカウントには、ターゲットの運用サーバーに対する sysadmin 権限がありました。

シングルトン パターンには多くの欠点があり、パターンを完全に避けることを提案する人さえいることに、多くの人が同意しているようです。ここに素晴らしい議論があります。Singleton パターンに関するコメントは、その質問に送ってください。

私の質問: 避けるべき、または細心の注意を払って使用する必要がある他の設計パターンはありますか?

これについての議論をどこかで見たのを覚えています。現在、私が取り組んでいるシステム内のすべてのビジネス オブジェクトが継承するベース オブジェクトを削除することを検討しています。これには、いくつかのプロパティ、いくつかのデータベース ロジック、およびいくつかのコンストラクタ ロジックが含まれています。

これはアンチパターンですか、それとも陪審はまだ出ていませんか? 各オブジェクトで一定量のボイラープレートコーディングを行う必要がある、継承元の基本コントラクトを用意したほうがよいでしょうか?

編集：私はdsimchaが好きで、問題に非常によく反映されていると感じています。さらに回答があればうれしいです

オブジェクト指向プログラミングの典型的な問題はダイヤモンド問題です。親クラス A と 2 つのサブクラス B および C があります。A には抽象メソッドがあり、B と C はそれを実装します。これで、BとCを継承するサブクラス D ができました。ひし形の問題は、D が B の実装と C の実装のどちらを使用するかということです。

人々は、Java はダイヤモンドの問題を知らないと主張します。インターフェイスを使用した多重継承のみを行うことができます。それらには実装がないため、ダイヤモンドの問題はありません。これは本当ですか？私はそうは思わない。下記参照：

【取り外し車両例】

ひし形の問題は常に悪いクラス設計の原因であり、プログラマーもコンパイラーも解決する必要のないものですか?

更新: 私の例の選択が不十分だったのかもしれません。

この画像を見る

_{(出典: suffolk.edu )}

もちろん、Person を C++ で仮想化することもできるため、メモリ内には person のインスタンスが 1 つしかありませんが、実際の問題は解決しません。GradTeachingFellow の getDepartment() をどのように実装しますか? 考えてみてください、彼はある学部の学生であり、別の学部で教えているかもしれません。したがって、一方または他方の部門を返すことができます。問題の完全な解決策はなく、実装が継承されない可能性がある (たとえば、Student と Teacher の両方がインターフェイスになる可能性がある) という事実は、私には問題を解決していないようです。

特定の設計状況から、一見簡単そうに見えるが間違った方法を取ることがあるのは私だけでしょうか? 私は疑わしい Singleton オブジェクトの分け前を作ったことを認めます。それに加えて、物事を簡単に見せるために、神のオブジェクトを 1 つまたは 2 つ作成することで知られています。

すべきではないとわかっていても、アンチパターンを使用したことがありますか?

そのため、別の投稿で次の「悪い」スニペットを見ましたが、私が見た唯一の代替手段は、Python にパッチを当てることです。

この「アンチパターン」を回避するにはどうすればよいですか?

私は古典的なエンタープライズ アプリケーションについて話しています。通常、ある種のアプリケーション サーバーまたはコンテナーでホストされます。エンティティ、サービス、プレゼンテーション/UI、およびリレーショナル ストレージだけです。

synchronizedそのようなアプリケーションで (メソッドまたはブロックのいずれかの) キーワードを見るたびに、私は非常に疑わしくなります。私の意見では、これは基本的なアーキテクチャの概念 (たとえば、ドメイン モデルが複数のクライアント間で共有されていないなど) を理解していないことの兆候であるか、さらに悪いことに、アーキテクチャが実際には非常に失敗している兆候です。

ここで私の考え方を共有しますか？それとも私は完全に軌道から外れていますか？従来のエンタープライズ アプリケーションで実際に同期が必要なユース ケースはありますか?

ステージング テーブルは、rpc (Java RMI や何らかの Web サービス呼び出しなど) またはメッセージング キュー (JMS など) がより適切なソリューションである場合に使用されるアンチ パターンですか? それとも、ステージング テーブルの方が適している問題はありますか?

明確にするために：

ステージング テーブルとは、プロセスによってレコードがテーブルに追加され、2 つまたは複数のプロセスによって読み取られ、処理される場合を意味します。間隔の終了ステータス (1 日の終わり、支払い期間の終了など) を反映することを意図したテーブルについて言及しているのではありません。ほとんどの場合、ステージング テーブルのスキーマは、顧客やアカウントなどのアプリケーション データ型を厳密に模倣しています。

このアンチパターンの潜在的な原因:

1) 2 つのプロセスの所有者間のビジネス ユニット ウォールは、ステージングへの書き込みまたは読み取りを行うプロセスが変更されるのを防ぎます。

2) ステージングへの書き込みまたはステージングからの読み取りプロセスの信頼性が低いため、開発者は「何かが失敗した場合に」データの損失を防ぐためにテーブルを使用するようになります

3) 知識の欠如または DGAS (^%$@ を与えないでください) の態度

時期尚早の最適化については誰もが聞いたことがあると思いますが、時期尚早のリファクタリングについてどう思いますか? あなたの意見にそのようなものはありますか？これが私が得ているものです。

まず、Martin Fowler の影響力のある著書"Refactoring"を読んだことで、プログラミングに関する私の人生が文字通り変わりました。

ただし、クラスやフレームワークのリファクタリングを急ぎ始めると、いわばコーナーにコーディングされていることに気付くことがあります。さて、問題は実際にはリファクタリング自体ではなく、時期尚早/不十分な設計上の決定/仮定であると思われます。

この問題に関するあなたの考え、洞察、および/または意見は何ですか? この問題に関連するアドバイスや一般的なアンチパターンはありますか?

編集：

あなたの回答を読んで、この問題をさらに考えてみると、この場合の問題は実際には「時期尚早の設計」の問題であり、必ずしも「時期尚早のリファクタリング」ではないことに気付いたと思います。私は、コーディング プロセスの早い段階で、設計を想定し、その方向にリファクタリングするという罪を犯してきました。ある程度のデザイン不可知論を維持し、クリーンなコードに向けたリファクタリングに集中するための少しの忍耐があれば、これらのデザインのうさぎの道をたどることはできません。