[Java-collab] geometry factory vs interface

[Jorge Piera]

Hello.
>
>> 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.
I think that one of the main goals of this project has to be to define
an API for geometries and the usage of Interfaces is normally more
flexible that the usage of abstract classes. I always prefer to define a
Interface and a default implementation for this Interface.

In the proposal of interfaces that Markus did I've seen methods like:

- public boolean isBeyond( Geometry geometry, Measure distance );
- public boolean isWithin( Geometry geometry );
- public boolean overlaps( Geometry geometry );
- ...

that are not refered to the geometry structure. They are operations! We
have to separate structure of functionality and I suggest that all these
methods have not to be here.

In gvSIG we have replaced all these methods by just one:

- public Object invokeOperation(int index, GeometryOperationContext ctx)

Details can be found here [1]. Yes, we know that we are losing
performance with this option but we are winning in other issues:

- The Geometry Interface is always the same (we don't have the problem
that has been commented above).
- Using this system is possible to provide a new implementation of one
concrete operation associated to a GeometryType and it is not necessary
to update the GeometryType (separation between structure and functionality).
>> 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.
Point has to be always an Interface. We can have the classes Point2D,
Point3D.... and we can not make a "new" of any of them. We can maybe use
the Builder pattern to provide different sets of geometries.

In gvSIG it is possible to add your own implementation of GeometryType
separately and we have a "GeometryManager" to create them:

Point point = geometryManager.createPoint(2);

2 is the dimension of the geometry. We have a faster way to create a
point in 2 dimensions using the method:

Point point = geometryManager.createPoint(0,1, 2);

It works because a "point in 2 dimensions" has been previously
registered on our manager and everyone can register its own
implementation of a Point2D.
>> 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
I agree with Jody.

It looks that I want to use the same geometry management system that we
are using on gvSIG: this is not true! One of our goals has been to have
a configurable and extensible geometry management system and I only
comment our examples to give you other vision on our common goal.

Regards,
Jorge

[1]
http://www.gvsig.org/web/docdev/docs/v2_0/org.gvsig.fmap.geom/view?set_language=en


-- 
Jorge Piera Llodrá
Especialista en Servicios OGC
Equipo de desarrollo gvSIG
IVER TI S.A.
C/ Lérida, 20
46009-Valencia (Spain)
Tlf.+34902252540
www.iver.es
www.gvsig.com