I was mostly thinking about what method and class names users see
when they use jclouds apis - we have Options a lot, we have Builders
as well.
Well, I think since we're talking here about builders that create
domain objects , rather than builders which create options in the
current jclouds sense of modifying a call, I would say:
createBuilder() // convenience method
-> CreateBuilder // Builder class
-> CreateObject // domain object
and similarly for update.
Admittedly, this doesn't take into account Everett's point about these
really being method options that happen to inherit from domain objects
for convenience (I hope I'm paraphrasing that correctly). If we prefer
that slant, I would go for something like:
createBuilder() // convenience method
-> CreateBuilder // Builder class
-> CreateParams or CreateSpec // method args
But *Params also isn't ideal because we already have *Params objects
in jclouds, and they're something slightly different. We *also* have a
*Spec class [2], which seems to come a little closer to the intention
here.
ap
[1]
https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/rest/annotations/FormParams.java
[2]
https://github.com/jclouds/jclouds/blob/master/providers/glesys/src/main/java/org/jclouds/glesys/domain/ServerSpec.java
