バイナリデータファイルを取得し、その一部をオブジェクトに解析し、結果のデータをデータベースに保存するための設計パターンを推奨する人はいますか?
同様のパターンを使用して、XML またはタブ区切りファイルを取得し、それを代表的なオブジェクトに解析できると思います。
一般的なデータ構造には次のものが含まれます。
(ヘッダー) (DataElement1) (DataElement1SubData1) (DataElement1SubData2)(DataElement2) (DataElement2SubData1) (DataElement2SubData2) (EOF)
良い設計には、ファイルの種類またはヘッダーに含まれる定義済みのメタデータに基づいて解析定義を変更する方法が含まれると思います。したがって、ファクトリ パターンは、パーサー パーツの全体的な設計の一部になります。
これを完了すると、実際に問題/解決策について合理的な考えが得られます。
現在、頭の中に理論が浮かんでいるだけで、そのほとんどは間違った方向に導かれていることがわかります.
ステップ 3: 容赦なくリファクタリングする。あなたの目的は、コードの約半分を削除することです
最後に、コードが既存のデザイン パターンに似ているか、新しいデザイン パターンを作成したことがわかります。これで、この質問に答える資格が得られます :-)
私は Orion Edwards に完全に同意します。それは通常、私が問題に取り組む方法です。しかし最近、狂気にいくつかのパターン (!) を見始めています。
より複雑なタスクの場合、通常、ビルダー(またはfactory ) を使用してデータの各部分を作成するインタープリター(またはstrategy )のようなものを使用します。
ストリーミング データの場合、パーサー全体がアダプタのように見え、ストリーム オブジェクトからオブジェクト ストリーム (通常は単なるキュー) に適応します。
あなたの例では、内部データ要素（インタープリターによって供給される）のビルダーを内部的に使用する完全なデータ構造（頭からEOFまで）のビルダーが1つある可能性があります。EOF に遭遇すると、オブジェクトが発行されます。
ただし、いくつかのファクトリ関数の switch ステートメントで作成されたオブジェクトは、おそらく多くのより少ないタスクにとって最も簡単な方法です。また、いつ誰かが同時実行性を押し付けてくるかわからないので、データ オブジェクトを不変に保つのが好きです :)
LexとYACCを使用します。今後10年間をこのテーマに専念しない限り、毎回、より優れた、より高速なコードが生成されます。
戦略パターンは、おそらくあなたが見たいものです。戦略はファイル解析アルゴリズムです。
次に、データベース挿入のための別の戦略が必要です。