[Java-collab] geometry factory vs interface

[Jody Garnett]

On 12/08/2009, at 3:58 AM, Markus Schneider wrote:

> Concerning interfaces vs. classes: I agree that it's good to keep it  
> as simple as possible, so one should provide
> classes whenever we can rule out that different implementations just  
> don't make sense.

I understand the temptation; and agree we will probably go with  
interfaces/factory/builder? However I wonder if that is a decision  
being made to make our life as library providers easier; and may not  
be in the  best interest of adoption and ease of use by developers?

The central implementation decision we need to have flexibility with  
is the implementation of operations behind the various geometry  
methods; this is t he point where we need to grow the library over  
time. The actual front end (ie geometry data structure) will probably  
not change much; and we may consider using classes. Even if it does  
change it is easier to add methods to classes then it is to interfaces.

To follow up on that last point it is often a good idea to use  
abstract classes rather then interfaces where possible.

> Especially, for Point and Envelope I would also like to have  
> constructors alternatively to a factory:
>
> Point p = new Point (0,1);
>
> is just nicer to write than
>
> GeometryFactory.getInstance().createPoint (0,1);

You have highlighted one place where I was sure I would need an  
interface :-) Indeed when a Points data structure provides access to a  
single Point it often would use a light weight implementation of Point  
that would delegate onto the backing double[] for example. Or another  
implementation could make use of a List<PointImpl> etc... I see later  
in this email you talk about recycling a Point object when iterating;  
to accomplish this you will need to define Point as a data object and  
add equals and hashcode to the interface.

> But I can very well imagine rather important use cases for having  
> multiple implementations of the geometry types:
> - A straightforward implementation that just provides beans for the  
> interfaces.
Fair enough.

> - An implementation that is backed by JTS, i.e. that actually uses  
> JTS objects to represent SFS geometries.

Long term I would recommend using JTS to implement the operations; and  
not tie it directly into the implementation of a set of geometry  
classes.

> - Implementations that are backed by Oracle / PostGIS geometry types

I am not really interested in this one. Let me think about it.

Well actually I could be. If we had our front end geometry data  
structures - which would basically act as an adapter between an  
original Oracle SDO_GEOMETRY Struct and a host of operation  
implementations (some using JTS, some using geodetic implementations  
etc...) it would be a pretty good story.

Okay that could be very nice; you would not accept the unpacking over  
head - just wrap around the "origional" geometry object. A few  
operations may be implemented directly (toEnvelope() for example); and  
the rest relying on the geometry api to present a unified view of the  
data to the appropriate operations.

As you can see I am very attracted to this from an implementation  
standpoint; I just worry the above benefit represents a "happy place  
in the future" and we may have a better short term "right here right  
now" in terms of library adoption if we make use of classes.

> I would opt for keeping the interfaces ease experimenting with  
> different implementations.
> I also think that providing factories can make it easier for novice  
> users to approach the quite intricate geometry type
> system. In deegree 3, we currently have a small factory for people  
> with simple geometry needs (SFS):
>
> - https://svn.wald.intevation.org/svn/deegree/deegree3/core/trunk/src/org/deegree/geometry/SimpleGeometryFactory.java
>
> and one for those who need all the complex stuff
>
> - https://svn.wald.intevation.org/svn/deegree/deegree3/core/trunk/src/org/deegree/geometry/GeometryFactory.java

I really like the direction of different factories for different  
target communities. One thing we have moved to in the geotools code  
base is:
- the creation of a simple complete factory with no logic and no  
duplication
- the creation of a "builder" that uses a factory; but is willing to  
use logic and duplication; and default values and so on to make  
constructing and code examples easier

Jody
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/java-collab/attachments/20090812/87df90be/attachment-0001.html