> + > +In addition to fixing these issues, jclouds wants to provide developers with > some compiler checks and other syntactic sugar (fluent builders), while also > supporting different updating, creating, or listing validation strategies. > + > +We want to > + > +1. Ensure object immutability. > +2. Utilize the fluent builder pattern. > +3. Ensure that "create" objects can only be used for create; update for > update; and listed resources cannot be directly sent back to the service. > +4. Reuse code and keep domain classes > [DRY](http://en.wikipedia.org/wiki/Don't_repeat_yourself). > +5. Allow using different validation strategies (for example, create vs > update). > + > +We have been able to identify a pattern that addresses these issues. Here is > some [sample > code](https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-neutron/src/main/java/org/jclouds/openstack/neutron/v2/domain/Router.java). > + > +This approach reuses code by having > [GSON](https://code.google.com/p/google-gson/) handle the domain objects > directly, as much as possible, both for serialization and deserialization, > thus eliminating map-binders and parsers in most cases. The domain classes > annotate their member variables using the @Named (for serialization) and > @ConstructorProperties (for deserialization) annotations. > + > +Many of the JSON attributes in Neutron are optional. GSON's jclouds > configuration supports such optional values by using @Nullable and boxed > types. An alternate supported method, more convoluted, implements Optional<T> > private member variables and getter return types.
Code font for `@Nullable` and `Optional<T>`? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-site/pull/124/files#r17126365
