問題タブ [anti-patterns]

製品と従業員のテーブルを持つデータベースについて考えてみます。現在の製品マネージャーをモデル化するための新しい要件があり、製品を担当する唯一の従業員であり、一部の製品は製品マネージャーを必要としないほど単純または成熟していることに注意してください。つまり、各製品には0個または1個の製品マネージャーを含めることができます。

アプローチ1：テーブルを変更して、新しい可能な列Productを追加し、製品マネージャーのない製品が値によってモデル化されるようにします。NULLproduct_manager_employee_IDNULL

アプローチ2：不可能な列と、に一意の制約を設定した新しいテーブルを作成しProductManagersます。これにより、製品マネージャーのない製品は、このテーブルに行がないことでモデル化されます。NULLproduct_IDemployee_IDproduct_ID

他のアプローチもありますが、これらは私が最も頻繁に遭遇するように思われる2つです。

これらが両方とも（私が信じる傾向があるように）正当なデザインの選択であり、単に異なるスタイルを表すと仮定すると、それらには名前がありますか？私はアプローチ2を好み、実際の例を使用せずにアプローチ1を好む人にスタイルの違いを伝えるのは難しいと思います（ここで行ったように！）傾向-方向-6NF（または何でも）自分自身をスタイルします。」

これらのアプローチの1つが実際にアンチパターンであると仮定すると（2つのエンティティ間の関係をそれらのエンティティの1つの属性としてモデル化することにより、アプローチ1の場合であると私は思うので）、このアンチパターンには名前がありますか？

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

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

私が勤務先にいる数年間で、アンチパターンと見なすものへの明確な傾向に気づきました。それは、内部データをXMLの大きな文字列として維持することです。私はこれが多くの異なる方法で行われるのを見てきましたが、2人の最悪の犯罪者は非常に似ていました。

Webサービス

最初のアプリケーションであるWebサービスは、SQLデータベース内の潜在的に大量のデータへのアクセスを提供します。起動時に、データベースから多かれ少なかれすべてのデータを引き出し、XMLとしてメモリに保存します。（3回。）このアプリケーションの所有者は、これをキャッシュと呼びます。私はそれを遅いと呼んでいます。なぜなら、これに対処している間に遭遇したすべてのパフォーマンスの問題は、このことを直接追跡できるからです。（これは企業環境であるため、クライアントがサービスではなくパフォーマンスの失敗のせいにされるのは当然のことです。）このアプリケーションはXMLDOMを使用します。

インポーター

2番目のアプリケーションは、サードパーティのデータベースからのエクスポートの結果として生成されたXMLファイルを読み取ります。目標は、このデータを（私たちが所有する）独自のシステムにインポートすることです。これを実行するアプリケーションは、XMLファイル全体を読み込み、インポートシーケンス全体を通じてXMLファイルのコピーを少なくとも2つ、場合によっては4つ保持します。データは操作、変換、およびインポートが行われる前に構成が行われる可能性があるため、インポーターはこのデータを生涯にわたってXML形式で所有することに注意してください。当然のことながら、このインポーターは、適度なサイズのXMLファイルが提供されると爆発します。このアプリケーションは、そのコピーの1つにのみXML DOMを使用し、残りはすべて生のXML文字列です。

私の常識的な理解では、XMLはデータをメモリ内に保持するのに適した形式ではなく、データを出力/転送するときにXMLに変換し、読み込みおよびインポートするときに内部データ構造に変換する必要があります。重要なのは、スケーラビリティの問題を完全に無視する本番コードに常に遭遇しており、そうするために多大な労力を費やしているということです。（これらのアプリケーションでの文字列解析の膨大な量は恐ろしいものです。）

これは、他の人が失敗した仕事に適切なツールを適用するための一般的な失敗ですか？それとも私の側の運が悪いだけですか？それとも、大量のデータをXMLとしてメモリに保存することが正しく、OKであるという、目がくらむほど明白で良い状況を見逃しているのでしょうか。

コンピュータプログラムが大きな泥だんごに変わる原因は何ですか？このアンチパターンから回復することは可能ですか？適用できる実証済みのリファクタリング方法はありますか？

ウィキペディアでシングルトンの記事を読んでいたところ、次の例に出くわしました。

この Singleton の動作はとても気に入っていますが、引数をコンストラクターに組み込むためにそれを適応させる方法がわかりません。Javaでこれを行うための推奨される方法は何ですか? 私はこのようなことをしなければなりませんか？

ありがとう！

編集: Singleton を使用したいという私の願望から、論争の嵐が巻き起こったと思います。私の動機を説明させてください。誰かがより良いアイデアを提案できることを願っています. タスクを並行して実行するために、グリッド コンピューティング フレームワークを使用しています。一般的に、私は次のようなものを持っています：

データへの参照をすべてのタスクに渡すだけでも、タスクがシリアル化されると、データが何度もコピーされます。私がやりたいことは、すべてのタスク間でオブジェクトを共有することです。当然、次のようにクラスを変更する可能性があります。

ご覧のとおり、ここでも、最初のファイル パスが渡された後は別のファイル パスを渡しても意味がないという問題があります。これが、回答に掲載された店のアイデアが好きな理由です。とにかく、ファイルをロードするためのロジックを run メソッドに含めるのではなく、このロジックを Singleton クラスに抽象化したかったのです。これ以上例を挙げることはしませんが、理解していただければ幸いです。私がやろうとしていることを達成するためのよりエレガントな方法について、あなたのアイデアを聞かせてください。ありがとうございました！

状況は次のとおりです。やりすぎているクラスがあります。主に構成情報にアクセスするためのものですが、データベース接続もあります。これはシングルトンとして実装されているため、ほとんどのコードが非常に緊密に結合されているため、単体テストも困難になります。これは、インポート時の依存関係を作成するため (Python でこれを行っています)、さらに問題が大きくなります。これは、特定のモジュールを特定の順序でインポートする必要があることを意味します。理想的には、これを 2 つのクラスに分割し、非シングルトンにしたいと考えています。

幸いなことに、私の雇用主は、この種のテストが優れているという事実を受け入れており、コードがよりテストしやすくなるのであれば、このような変更を喜んで許可してくれます。しかし、私がそれに多くの時間を費やすことを彼らが喜んで許してくれるかどうかは疑わしい. そして、過激になりすぎるのではなく、これを段階的に修正したいと思います。

したがって、ここには 3 つの選択肢があります。

1. 構成オブジェクトを (シングルトン) 構成オブジェクトと (非シングルトン) データベース オブジェクトに分割します。これにより、少なくともインポート時の依存関係としてデータベースを削除できます。
2. 構成オブジェクトを非シングルトンにして、それを必要とするオブジェクトに渡します。これは私たちの短期的なニーズによりよく対応していると思いますが、それにはかなり時間がかかると思います.
3. あなたがあなたの答えで提案することを私が考えていなかった何かをしてください。:-)

それで、私は何をしますか？

Java クラスでは、getter と setter を使用してメンバー フィールドにアクセスするのは良い習慣ですか、それとも悪い習慣ですか?

たとえば、どちらが良いですか：

一般に、KISS の原則により、フィールドに直接アクセスするのが最善であり、誰かが後で get メソッドをオーバーライドして予測できない結果になる可能性があると思います。

しかし、私の同僚は、抽象化のレイヤーを保持する方が良いと主張しています。これについてコンセンサスはありますか？

C# や Java などの他の言語で大きな GUI ベースのアプリケーションを構築する場合、MVP、MVC、MVVM などのさまざまなパターンがあり、Prism (WPF/Silerlight) などの完全なガイダンス パッケージもあり、コードを保守可能、拡張可能、複雑に保つのに役立ちます。健全なレベルでのアプリケーションの。

しかし、html/javascript で作成された大きな RIA アプリケーションに関しては、本当に優れたリソースを見つけるのは難しいと思います。

html/javascript で大きな RIA アプリケーションを作成する場合 (Gmail、Google カレンダー、Google ドキュメントなどのアプリケーションを作成する場合) のすべきこととすべきでないことは何ですか?

最近、注目を集めた「貧血ドメインモデルパターン」の投稿を読みました。これを読んでいると、貧血ドメインモデルの説明が、私が取り組んで構築したプロジェクトの多くに適用されていることがわかりました。非常に自然に感じたので、これを悪い設計上の決定だとは思いませんでした。ドメインモデルが軽量でそれほど複雑ではない場合、AnemicDomainModelモニカは非常によく合うと思いました。「貧血ドメインモデル」のタイトルがコードを適切に説明していないのに、ドメインモデルに複雑さを加える必要がないのはなぜですか。

質問：どの時点で、コードの複雑さをサービス/アプリケーションレイヤーに詰め込むことが正しくなくなり、代わりにエンティティオブジェクトの複雑さを明らかにすることになりますか？私はすべて、エンティティに「合計」プロパティを持っていて、内部で合計の値を把握できるようにしています。私は、エンティティを他のさまざまなウィジェットと直接通信させて、そのプロパティの1つの結果を決定するためのものではありません。では、貧血ドメインモデルの概念は、アンチパターンですか、それとも関心の分離ですか？タイトルの貧血ドメインモデルは常に悪いことですか？

このデザイン（アンチ）パターンについて他の人の考えがどうだったか興味があります。