2011-12-05 44 views
2

我目前使用这里定义生成器模式:如何使用构建器模式构建各种类似的对象类型?

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 

ZipHolderFile都是由u唱生成器模式,作为每个静态类的内部实现。 A ZipHoldermainFile作为必需的构造函数参数,并预填充ZipHolder中的某些信息,如果需要,可以将其覆盖。 A File包含与该文件有关的文件内容和关联的元数据。然后在调用每个Builder类的build()方法时,对ZipHolderFile进行验证。然后将对象取出并输出到ZIP文件层次结构,然后根据需要读入相同的对象结构。

这很好地工作,并在确保不变性的同时给予对象创建的一定程度的灵活性。但我遇到了一个问题。新的要求已经出现,要求File对象可以具有元数据文件内容只有文件内容。我想我可以简单地将一个布尔标志值传递给ZipHolder对象的构建器,以允许跳过通常的元数据验证。这似乎确定,但它然后需要构建一个FilemainFile - 基本上,鸡和鸡蛋的情况。我的下一个想法是将国旗移至File班。这似乎是好的,直到我意识到你可能创建多个File对象,其中一些需要元数据,而另一些对象只有文件内容,并没有在整个板上强制实施约束的方法。

所以我有点难倒如何继续。我看不出一种明显的方式,以优雅的方式将mainFile的要求解耦为ZipHolder。像抽象类,接口,基类和类似的概念让人想起,但在这种特殊情况下我需要一些方向。

所以我的问题是:

我可以允许这两种情况下,同时保持每原因生成器模式在我上面的链接?

回答

1

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

+0

对不起,我迟到的回应。这个问题或多或少地需要有一个基类的子类。在我的例子中,子类将拥有额外的文件内容。所以我想,考虑到每个File类型的类都有一个内部静态构建器类,我不太确定如何最好地实现基本上重复的工作。我的构建器模式的目标是不变性,易于使用可选/强制参数构建复杂对象以及验证。所以我想要更进一步,使用适合我想实现的构建模式。 – speedRS

相关问题