如何使用构建器模式来构造各种相似的对象类型?

发布于 2024-12-19 07:39:33 字数 1416 浏览 3 评论 0原文

我目前正在使用此处定义的构建器模式:

显示我使用构建器模式的问题

我现在遇到的问题是需要创建以下结构:

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

或者:

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

ZipHolderFile 均已构造使用构建器模式,作为每个模式的内部静态类实现。 ZipHoldermainFile 作为强制构造函数参数,并在 ZipHolder 中预填充一些信息,如果需要,可以覆盖这些信息。 File 包含文件内容以及与该文件相关的元数据。然后,在调用每个 Builder 类的 build() 方法时,对 ZipHolderFile 进行验证。然后,获取对象并将其输出到 ZIP 文件层次结构,然后根据需要将其读入相同的对象结构。

这工作得很好,并在确保不变性的同时为对象创建提供了一定程度的灵活性。不过我遇到了一个问题。出现了一项新要求,要求File对象可以具有元数据文件内容文件内容。我想我可以简单地将布尔标志值传递给 ZipHolder 对象的构建器,以允许跳过通常的元数据验证。这看起来没问题,但它需要构建一个 File mainFile - 本质上是先有鸡还是先有蛋的情况。我的下一个想法是将标志移至 File 类。这看起来没问题,直到我意识到您可能会创建多个 File 对象,其中一些对象需要元数据,而另一些对象仅包含文件内容,而无法全面强制执行约束。

所以我对如何继续感到有些困惑。我看不出有一种明显的方法可以以优雅的方式将 mainFile 的需求与 ZipHolder 解耦。我想到了诸如抽象类、接口、基类之类的概念,但在这种特殊情况下我需要一些指导。

所以我的问题是:

我可以允许这两种情况,同时根据上面链接中的原因保留构建器模式吗?

I am currently using the builder pattern as defined here:

Previous question showing my use of the builder pattern

The problem I've now encountered is a requirement to create the following structure:

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

OR:

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

Both ZipHolder and File are constructed using the builder pattern, implemented as an internal static class of each. A ZipHolder takes a mainFile as a mandatory constructor parameter and prefills some information in the ZipHolder, which can be overridden, should the need arise. A File contains file content and associated metadata pertaining to that file. Validation on both the ZipHolder and File is then performed when calling the build() method of each's Builder class. The objects are then taken and output to a ZIP file hierarchy that should then be read in to the same object structure, if required.

This works nicely and gives a degree of flexibility in object creation while ensuring immutability. I have encountered a problem though. A new requirement has presented itself, mandating that File objects can either have metadata and file content OR only file content. I figured I could simply pass a boolean flag value to the builder for the ZipHolder object to allow the skipping of the usual metadata validation. This would seem ok but then it requires a File mainFile to be constructed - essentially, a chicken and egg situation. My next thought was to move the flag to the File class. This seemed ok until I realised that you could potentially create multiple File objects, some with metadata required and others with only the file content, with no means of enforcing constraints across the board.

So I am somewhat stumped as to how to proceed. I can't see an obvious means of decoupling the requirement of a mainFile for a ZipHolder in an elegant fashion. Concepts like abstract classes, interfaces, base classes and things like that come to mind but I'm in need of some direction in this particular situation.

So my question is:

Can I allow for both scenarios while retaining the builder pattern per the reasons in my link above?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

待天淡蓝洁白时 2024-12-26 07:39:33

我不太明白这个问题,但你可能应该创建一个类 MainFile extends File,在那里实现约束并要求用户将 MainFile 实例传递给 ZipHolder 工厂。

I didn't quite understand the problem but you should probably make a class MainFile extends File, implement constraints there and require the user to pass a MainFile instance to ZipHolder factory.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文