[Java-collab] Re: geometry factory vs interface

[Markus Schneider]

Hi Jody,

Jody Garnett wrote:
> >
> > On 12/08/2009, at 3:58 AM, Markus Schneider wrote:
> >
 > 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.

Sure. Especially when we have to maintain both the interfaces and the implementation(s), this definitely gets
cumbersome. But as I already pointed out in some other mail, I honestly think we should keep the door open for different
implementations.

Concerning usability, I don't feel that using Factories or beans usually makes that much of a difference. My experience
is that you usually only have to create Point and Envelope instances manually inside Java code. Complexer constructs are
usually created from some external representation (GML, Shapefile, DB) anyway -- and for this, a GIS API would of course
provide easy-to-use ways that performs the geometry creation for the user.

> > 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.

Actually, the current code in deegree 3 creates Points instances whenever large numbers of Point occur (e.g. in GML).
However, a user can still create individual Point instances manually (using the constructor of the Point implementation
or the factory). Of course, this should only be done for rather small numbers of Point objects.

> > 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.

Sure. Therefore I would suggest to add a (most simple) implementation ASAP, that just provides the beans for creating
and navigating the geometries.

Best regards (and on to the next subject),
Markus

-- 
Markus Schneider

l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 +228 184960       fax ++49 +228 1849629
http://www.lat-lon.de        http://www.deegree.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.osgeo.org/pipermail/java-collab/attachments/20090820/b9b8183c/signature.bin