0

事実

テーブルと属性のリスト（簡略化）で構成される次のデータ構造があります。

class Table {
    List<Attribute> m_attributes;
}

abstract class Attribute {}

class LongAttribute extends Attribute {}
class StringAttribute extends Attribute {}
class DateAttribute extends Attribute {}
...

今、このデータ構造でさまざまなアクションを実行したいと考えています:

  • XML表記で出力する
  • テキスト形式で印刷する
  • SQL 挿入ステートメントを作成する
  • SQL 更新ステートメントを作成する
  • SQL結果セットから初期化する

初挑戦

私の最初の試みは、これらすべての機能を 内に配置することでしAttributeたが、その後、Attributeは非常に異なる責任で過負荷になりました。

別

代わりにビジター パターンが非常にうまく機能するように思えますが、逆に言えば、この単純な構造にはやり過ぎのように見えます。

質問

これを解決する最もエレガントな方法は何ですか?

4

4 に答える 4

1

コマンドパターン、またはその小さなバリエーションが思い浮かびます。

たくさんのクラスがあり、それぞれがデータクラスで特定のことを行うために特化されています。これらのクラスは、ハッシュマップまたは外部の選択で実行用に選択できるその他の構造に保持できます。これを行うには、データを引数として、選択したコマンドのexecute（）メソッドを呼び出します。

編集：詳細。

最下位レベルでは、データ行の各属性を使用して何かを行う必要があります。これは確かにVisitorパターンの場合のように聞こえます。Visitorは、変数「victim」オブジェクトをメソッドにカプセル化された変数「operation」と組み合わせることができる限り、ダブルディスパッチ操作をシミュレートします。

すべての属性は、xml-ed、text-ed、insert-ed、updat-ed、およびinitialize-edである必要があります。したがって、3つの属性タイプのそれぞれに対してこれらの5つの操作のそれぞれを実行するために、5x3クラスのマトリックスになります。ビジターパターンの残りの機構は、属性のリストをトラバースし、各属性に対して正しい方法で選択した操作に正しいビジターを適用します。

15のクラスとインターフェースを書くのは少し重く聞こえます。これを行うことができ、非常に一般的で柔軟なソリューションが得られます。一方、解決策について考えているうちに、現在知られている構造のコードをハッキングして、クラスの形があまり頻繁に変更されないように指を交差させることができたはずです。

コマンドパターンについて考えたのは、さまざまな同様の操作の中から選択するためのものでした。実行する操作が文字列として（おそらくスクリプトや構成ファイルなどで）入ってくる場合は、

"xml" -> XmlifierCommand
"text" -> TextPrinterCommand
"serial" -> SerializerCommand

...これらの各コマンドは、適切なビジターを起動してジョブを実行します。ただし、操作はコードで決定される可能性が高いため、おそらくこれは必要ありません。

于 2009-11-10T07:37:06.130 に答える
1

JAXBとHibernateの組み合わせを使用することを検討します。

JAXBを使用すると、XMLからマーシャルおよびアンマーシャルできます。デフォルトでは、プロパティはプロパティと同じ名前の要素に変換されますが、@XmlElementおよび@XmlAttributeアノテーションを介して制御できます。

Hibernate（またはJPA）は、データベースとの間でデータオブジェクトを移動する標準的な方法です。

于 2009-11-10T07:39:07.123 に答える
1

最近、休止状態を使用するだけでなく、自分でデータベースにデータを保存する理由がわかりませんが、ここに私の呼び出しがあります:

LongAttribute、、、 …DateAttributeはStringAttributeすべて異なる内部 (つまり、属性クラスに存在しないそれらに固有のフィールド) を持っているため、それらすべてをシリアル化する 1 つのジェネリック メソッドを作成することはできません。現在、XML、SQL、およびプレーン テキストはすべて、シリアル化するときに異なるプロパティを持ちます。O(#outputformats の Attribute  #subclasses)* 異なるシリアライズ方法を書くことを避ける方法は本当にありません。

Visitorはシリアライズの悪いパターンではありません。確かに、再帰的でない構造で使用するのは少しやり過ぎですが、ランダムにコードを読んだプログラマーは、コードが何をしているかをすぐに把握できます。

デシリアライゼーション (XML からオブジェクトへ、SQL からオブジェクトへ) には、Factoryが必要です。

もう 1 つのヒントとして、SQL 更新の場合、古いバージョンのオブジェクトと新しいバージョンのオブジェクトを取り、それらの違いに対してのみ更新クエリを作成するものが必要になる可能性があります。

于 2009-11-10T18:43:52.427 に答える
0

最終的に、訪問者パターンを使用しました。今振り返ると、良い選択でした。

于 2010-02-04T16:51:26.793 に答える