Message-ID: <2054808871.300139.1369031453873.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_300138_1976389860.1369031453873" ------=_Part_300138_1976389860.1369031453873 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This article is in response to an excellent observation made by = Martin Fowler here:
This articles covers how to use Builders and Utility classes to make geo= tools easy.
As discussed elsewhere, geotools makes use of Interfaces and Factories <= strong>everywhere. To ease the burden on implementors we try for t= he minimal set of methods that will do the job. We also aggressively take t= his approach with standards, fostering off definition (and associated caref= ul documentation duties) on the GeoAPI project whenever we can.
So they don't line up yet, gives us something to work towards (or away f= rom).
What happens when you step away from the minimal interface? Let's consid= er the ones marked as "Funny"
To start with these methods involve creation, they are out of place in w= hat is otherwise a API focused on functionality (ie capturing what is neede= d for interoperability). This places a burden on implemententors that is ra= ther heavy - creation is a difficult problem!
To wit: the implementation will need to keep the Factory that created it= - so it can implement these methods.
It is true that the resulting interfaces are sometimes crazy to use (try= making a CRS by hand, or changing something in a FeatureType). You will go= crazy tring to do it once, you would be crazy to do it twice.
To address this need we have our utility classes:
Right now most of these utility classes consist of static final<= /strong> methods that do the right thing.
The use of Builders is closely related. These, by definition, are classe= s that put a pretty face on creation. As such they often provide a humane i= nterface beyond that available through a the minimal API required for inter= operability.
Here is how Builders are different: they are used specifically to ease t= he creation process. Often they appear as a pretty mutable= face on things that are hard to construct or immutable. StringBuffer is a = builder of Strings, FeatureTypeBuilder is a builder of FeatureTypes. Builde= rs that construct complicated content in this manner are stateful= strong>.
One of the things that is happening as we fix up the toolkit and make it= consistent is that these classes are moving away from being full of static= final methods....
Why you ask? Because it turns out most of the methods a= ctually need to do something and to do something you need to be connected u= p with GeoTools factories, a possible open-ended set of factories...
So lets look at the SLD utility class as an example.
This is a good example because:
This is a bad example because:
Chaining utility classes together like this allows us to minimize the ne= ed for explicitly showing a cascade of factory injection.
The practice makes no difference to whoever is setting us up, and even r= epresents less work for them.
To make SLD play nice with others we need to ensure that others can play= with SLD. Playing is called dependency injection (SLD will depend on them = to do some work after all). Setting this up is done in two ways.
You may have noticed that the above would of broken a lot of code - here= is the missing link:
This preserves backwards compatibility, it is deprecated (so it will be = removed in a future release). It does allow a hook for the default to be fo= rced by client application code, but since this cross cuts the entire VM it= is not recommended.
GIS is a tough nut to crack, often the task is to make things work at al= l. If you get a chance try and provide assistance to those using the toolki= t. This article illustrates how this can be done without consequence to int= eroptability.
An alternative approach would be to put all the fun convenience meth= ods into the implementations; this would be dangerous if w= e accidently started using them internally - and it would have the negative= consequence of locking users into a specific implementation.
The relationship between minimal interfaces and usability is a difficult= balance, the use of utility classes can act as a wrapper around the proble= m. Wrap up an implementation with a utility class for ease of use, just be = sure to allow for the network of required factories.
In the explicit case of creation Builders often allow for a more Humane = (and sometimes the only) take on the situtation.------=_Part_300138_1976389860.1369031453873--