This is a genuine, heartfelt plea: The Builder pattern
(DatastoreServiceConfig, FetchOptions) makes code extra annoying when
layering an API on top of the low-level API.
Let's say you are writing some code by hand that creates a
FetchOptions with a limit and an offset:
FetchOptions opts = FetchOptions.Builder.withLimit(100).offset(20);
Pretty straightforward when typing it out by hand, but the lack of
orthogonality between withLimit() and limit() is a PITA when you're
trying to automate the creation of a builder. The problem is, you
can't start with a "blank" FetchOptions. The result is we end up
writing lots of code like this:
if (limit != null)
{
if (opts == null)
opts = FetchOptions.Builder.withLimit(limit);
else
opts = opts.limit(limit);
}
This wouldn't be necessary if FetchOptions.Builder had a "create()"
method that would produce a blank FetchOptions. Or if FetchOptions
had a public constructor. Or if FetchOptions was an interface or even
a nonfinal class.
I notice that DatastoreServiceConfig is following in the path of
FetchOptions. My initial reaction was Noooooo! :-)
Thanks for listening,
Jeff
--
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
