> > Why a stream of input? As an example is a DOM tree > certainly not a stream, > > not has it necessarily been constructed from one, but it is > perfectly suited > > as input for an Ant project. In this case I think Object > as input makes > > perfectly sense as it should really be left up to the > implementor what kind > > of source he'd like to read the input from. But of course > he has to know > > that he will have to deal with File objects if he uses the > <ant> task or the > > like. In this case he might just delegate to the standard > > ProjectHelperImpl. > > > > I think the best analogy here is the way the JDOM API works. JDOM > provides the concept of a JDOMFactory interface whose > implementations are > the ones actually constructing the model (I would argue this > is the equivalent to > what we want ProjectHelper to be), and then you have several > *Builder classes > that direct the construction of the model from diferent > sources (DOMBuilder, > SAXBuilder, etc.). >
Yes, I've looked at that too, and it's indeed a very nice separation of concerns. > In such a model there is no need to pass "Object" parameters > around, things are well > typed and the compiler can do its proper job. > I see one problem here though: Currently the <ant> task directly uses the ProjectHelper to set up and call a project *referenced by File*. How would this work with the JDOM analogy? The <ant> task has to use the correct Builder and can only pass an URI (or File) as input. This probably means that all Builders are required to be able to handle URI (or File) type as input. And in addition to the Factory (ProjectFactory?) and the Builders you probably need a class with a static method which clients (like <ant>) can use to get a project using the correct Builder. I think this pattern could be hard to implement given the fact that it is not only used by client code (would be oat.ant.Main I guess) but also internally by the <ant> task. But maybe introducing a Builder interface with a method to load a project from an URI or File would suffice... -- knut
