Comment 1 for bug 487009

Here's the pre-implementation suggestion that I'm starting now:

---------- Forwarded message ----------
From: Michael Nelson <email address hidden>
Date: Mon, Nov 23, 2009 at 7:56 PM

OK, I had a bit of time to look at this today. Just in terms of a pre-implementation discussion, here's what I'm planning to do tomorrow - so if you see any flaws or improvements in my plan or assumptions, please let me know.

The specialized builders need to both (a) augment existing functionality (eg. startBuild()), and (b) provide some additional different functionality (eg. checkCanBuildForDistroArchSeries()).

My assumption is that all call-sites will know whether they want a specific type of builder, or be happy to deal with a set of general builders (ie. a view listing all builders).

The approach that I'm planning to take tomorrow is to (note bigjools, this is different to the initial example I showed you earlier):

1) Create IPackageBuilder (or IBinaryPackageBuilder) as an extension of the IBuilder interface.
2) Create a PackageBuilder (or BinaryPackageBuilder) content-class that uses composition + delegation to provide the IBuilder general functionality while adding custom functionality or augmenting existing functionality of IBuilder (using lazr.delegates).
3) Provide adapters for IBuilder->IPackageBuilder etc., so that call-sites can grab a builder and adapt it as required.
4) Where appropriate, provide hooks in any general Builder methods that will need additional behaviour so that customisations will generally (but not necessarily) follow a standard api.

Also, when a builder is building it will have a know job type and so can potentially adapt itself (via the job/build queue entry). Not sure if this will be necessary.

This means that the general IBuilder interface/class won't need to know about the specializations (or be updated when new specialized builders are added).