2

現在、ここで定義されているビルダー パターンを使用しています。

ビルダーパターンの使用を示す前の質問

私が今遭遇した問題は、次の構造を作成するための要件です。

- ZipHolder: file metadata present
    * File mainFile
    * File optionalFile
    * List<File> files

また：

- ZipHolder: no file metadata present
    * File mainFile
    * File optionalFile
    * List<File> files

ZipHolderとは両方ともFileビルダー パターンを使用して構築され、それぞれの内部静的クラスとして実装されます。Aは、必須のコンストラクタ パラメータとして をZipHolder取り、必要に応じてオーバーライドできる の一部の情報を事前に入力します。には、そのファイルに関連するファイル コンテンツと関連するメタデータが含まれます。との両方の検証は、それぞれのクラスのメソッドを呼び出すときに実行されます。次に、オブジェクトが取得され、必要に応じて同じオブジェクト構造に読み込まれる必要がある ZIP ファイル階層に出力されます。mainFileZipHolderFileZipHolderFilebuild()Builder

これはうまく機能し、不変性を確保しながらオブジェクト作成にある程度の柔軟性をもたらします。しかし、問題が発生しました。Fileオブジェクトがメタデータとファイル コンテンツを持つことも、ファイルコンテンツ のみを持つこともできるという、新しい要件が提示されました。ZipHolder通常のメタデータ検証をスキップできるようにするために、オブジェクトのビルダーにブール値のフラグ値を渡すだけでよいと考えました。これは問題ないように思えますが、File mainFileを構築する必要があります。つまり、鶏が先か卵が先かという状況です。次に考えたのは、フラグをFileクラスに移動することでした。複数を作成できる可能性があることに気付くまで、これは問題ないように思えましたFileオブジェクトには、メタデータが必要なものもあれば、ファイル コンテンツのみを含むものもあり、全面的に制約を適用する手段はありません。

そのため、どのように進めればよいのか、私はやや困惑しています。エレガントな方法でaのmainFileの要件を切り離す明確な手段がわかりませんZipHolder。抽象クラス、インターフェース、基本クラスなどの概念が頭に浮かびますが、この特定の状況で何らかの方向性が必要です。

だから私の質問は：

上記のリンクの理由に従ってビルダー パターンを保持しながら、両方のシナリオを許可できますか?

4

1 に答える 1

1

私は問題をよく理解していませんでしたが、おそらく class を作成し、MainFile extends Fileそこに制約を実装し、ユーザーに MainFile インスタンスを ZipHolder ファクトリに渡すように要求する必要があります。

于 2011-12-09T15:19:19.767 に答える