Objects, Interfaces and Factories

GeoTools loves its interfaces - this drove me mad when I first started using the toolkit. One of the things about an=
interface is that you still need a way to create objects, and that is wher=
e a factory comes in. A factory is simply a class with a crea=
te method.

AFT=
ER (aka interfaces/factory):

Why would you do this? Because you want to work with others - including =
people you have not yet met! The idea is someone can come along and give yo=
u their own FooFactory and all of a sudden your code is doing new and wonde=
rful things without evening noticing.

=20

Now the alert will notice there is a problem here. How the heck do you m=
ake a FooFactory? A FooFactoryFactory seems a bit silly ... let's work on b=
ootstrapping the process.

=20

BootStrapp=
ing Factories

=20

U=
sing a Plugin System (and Defaults)

=20

I have to continue with my above example for a bit ...

=20

=20

public class FooFinder(){
FooFactory[] list();
}

=20

=20

... the interesting thing here is that this class really is magi=
c. This is really the front end to the GeoTools plug-in system, we=
change the technology behind it every once in a while (but these FooFinder=
s will always work). Our usual goal for shopping for a plug-in system is th=
is: dropping a jar on the classpath and having more FooFactory instances sh=
ow up in that above list.

=20

Now we are usually a bit kinder then that and include some utility metho=
ds:

How and where the defaults come from, and even the order of that origina=
l list is all kind of a mystery to me. The good news is it rarely matters.<=
/p>=20

The exception to this rule is with EPSGAuthortyFactories: I end up contr=
oling the process by only including one of the jars on the=
classpath that I am interested in, but that is a lo tech answer.

=20

Let's see this in use:

=20

=20

Foo foo =3D FooFinder.create( 3 );
foo.doSomething();

=20

=20

That was not too bad, and we can manage to work with others - just as lo=
ng as they are setup as the default.

=20

U=
sing a Plugin System (and Metadata)

=20

The other thing to do is use the plugin system and wander through that l=
ist and make an intelligent choice. We have to get the factories to tell us=
something interesting to make that choice, and that something is called (<=
strong>cough) metadata.

=20

This time I am going to go for a bit more of a realistic example - Bar (=
okay not that much more real).

Note we also have getDisplayNames to show to users, and getName to write=
in configuration files. Fun.

=20

This is still a little bit backwards, it involves us knowing ahead of ti=
me (or at least asking a user) which factory to use. We can also turn=
the question around and ask the factory if it thinks it is up to the task.=

This is often called an AbstractFactory by the GOF(aka =
Patterns Police). You will see the GOF uses these with a Builder pattern to make interesting data structures like expressions and doc=
uments.

=20

=20

Using Fac=
tories together!

=20

So the question becomes what of a Factory that uses another Factory? Ann=
oying, but it is actually very common.

=20

In GeoTools we have the following chain:

=20

=20

FeatureTypeFactory makes FeatureType=20

=20

AttribtueTypeFactory makes AttribtueTypes

=20

=20

FeatureFactory makes Features=20

=20

GeometryFactory makes Geometry=20

=20

CoordianteSequenceFactory makes CoordinateSequences

=20

=20

=20

=20

The only simplifcation we currently have (by accident) is that FeatureTy=
pe is the FeatureFactory! There has to be a better way!

=20

Using a Container=

=20

That still seems like a lot of bother, you have to talk to two classes, =
a Finder and a Factory, before you ever get anywhere ... there has to be an=
easier way. And there is

=20

A container is a strange offshoot of the J2EE scene. The formal definiti=
on is something along the line of a "blackboard that supports lifecycl=
e" or something like that. Lifecycle being alpha and =
the omega of an Objects existence. A blackboard is a nice architecture that=
lets code loosely collaborate on stuff.

Mechanics of Setting up a Factory for Container Use

=20

I am just going to jot down some notes on how Containers formalize Facto=
ries working together. Oh they call this "dependency injection" a=
nd the whole process "Inversion of Control" (IoC) - I am going to=
let Justin explain that one.

=20

Because of this formalization, containers can do all sorts of magic that=
make this stuff easy to use and easy to write.