我目前正在使用此处定义的构建器模式:
Previous question showing my use of the builder pattern
我现在遇到的问题是需要创建以下结构:
- ZipHolder: file metadata present
* File mainFile
* File optionalFile
* List<File> files
OR:
- ZipHolder: no file metadata present
* File mainFile
* File optionalFile
* List<File> files
ZipHolder
和File
都是使用构建器模式构造的,实现为每个构建器的内部静态类。 ZipHolder
将mainFile
作为强制构造函数参数,并在ZipHolder
中预填充一些信息,如果需要,可以覆盖这些信息。 File
包含与该文件有关的文件内容和关联的元数据。然后,在调用每个ZipHolder
类的File
方法时,会对build()
和Builder
进行验证。然后获取对象并输出到ZIP文件层次结构,然后应根据需要将其读入同一对象结构。
这很好用,在对象创建方面提供了一定程度的灵活性,同时确保了不变性。我遇到了一个问题。一项新要求已经出现,要求File
个对象可以包含元数据和文件内容或 仅文件内容。我想我可以简单地将布尔标志值传递给ZipHolder
对象的构建器,以允许跳过通常的元数据验证。这似乎没问题但是它需要构建File
mainFile - 基本上是鸡和蛋的情况。我的下一个想法是将标志移动到File
类。这似乎没问题,直到我意识到你可能会创建多个File
对象,其中一些需要元数据,另一些只包含文件内容,而无法全面强制执行约束。
所以我对如何进行感到有点难过。我看不出以优雅的方式将{em> mainFile 的需求与ZipHolder
分离的明显方法。我想到了抽象类,接口,基类和类似事物之类的概念,但在这种特殊情况下我需要一些方向。
所以我的问题是:
根据上面链接中的原因,我可以同时保留构建器模式吗?
答案 0 :(得分:1)
我不太明白这个问题但你应该创建一个类MainFile extends File
,在那里实现约束并要求用户将一个MainFile实例传递给ZipHolder工厂。