> +Some [simpler > classes](https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-neutron/src/main/java/org/jclouds/openstack/neutron/v2/domain/AddressPair.java) > implement the regular fluent builder pattern. > + > +In [other > cases](https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-neutron/src/main/java/org/jclouds/openstack/neutron/v2/features/NetworkApi.java), > the same domain class has several different purposes, such as making sure > users have different Network-subtype object instances for updating, creating, > and listing networks: > + > +1. Listing networks returns a Network or a list of Networks. > +2. Updating a network requires Network.UpdateOptions. > +3. Creating a network requires Network.CreateOptions. > + > +CreateOptions and UpdateOptions extend Network and implement their own copy > constructors, with custom validation, if needed. > + > +To instantiate these create or update-specific objects, developers have > access to CreateBuilder and UpdateBuilder, which both extend the regular > Network builder abstract class. The only code these special builders > implement: the constructor (taking as parameters any required properties), a > build() method returning the create or update object, and also self(). The > self method is needed to make sure we can reuse most of the Builder code, but > still be able to chain the fluent builder methods. > + > +This is how it all works out from the developer's perspective: > + > +{% highlight Java %} > +Network.CreateOptions createNetwork = Network.createOptions("jclouds-wibble")
Interesting example: here, the domain object subtypes are pretty visible. Is that the intention? Or so you see people calling the API call directly, without creating this intervening object and (thus) exposing this subtype? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-site/pull/124/files#r17126468
