如何使用构建器模式来构造各种相似的对象类型?
我目前正在使用此处定义的构建器模式:
我现在遇到的问题是需要创建以下结构:
- 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
均已构造使用构建器模式,作为每个模式的内部静态类实现。 ZipHolder
将 mainFile
作为强制构造函数参数,并在 ZipHolder
中预填充一些信息,如果需要,可以覆盖这些信息。 File
包含文件内容以及与该文件相关的元数据。然后,在调用每个 Builder
类的 build()
方法时,对 ZipHolder
和 File
进行验证。然后,获取对象并将其输出到 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 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我不太明白这个问题,但你可能应该创建一个类
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.