<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 12/08/2009, at 3:58 AM, Markus Schneider wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Concerning interfaces vs. classes: I agree that it's good to keep it as simple as possible, so one should provide<br>classes whenever we can rule out that different implementations just don't make sense.</div></blockquote><div><br></div>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?</div><div><br></div><div>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.</div><div><br></div><div>To follow up on that last point it is often a good idea to use abstract classes rather then interfaces where possible.</div><div><br><blockquote type="cite"><div>Especially, for Point and Envelope I would also like to have constructors alternatively to a factory:<br><br>Point p = new Point (0,1);<br><br>is just nicer to write than<br><br>GeometryFactory.getInstance().createPoint (0,1);<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div>But I can very well imagine rather important use cases for having multiple implementations of the geometry types:<br>- A straightforward implementation that just provides beans for the interfaces.<br></div></blockquote>Fair enough.</div><div><br><blockquote type="cite"><div>- An implementation that is backed by JTS, i.e. that actually uses JTS objects to represent SFS geometries.<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div>- Implementations that are backed by Oracle / PostGIS geometry types<br></div></blockquote><div><br></div>I am not really interested in this one. Let me think about it.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br><blockquote type="cite"><div>I would opt for keeping the interfaces ease experimenting with different implementations.</div></blockquote><blockquote type="cite"><div>I also think that providing factories can make it easier for novice users to approach the quite intricate geometry type</div></blockquote><blockquote type="cite"><div>system. In deegree 3, we currently have a small factory for people with simple geometry needs (SFS):<br><br>- <a href="https://svn.wald.intevation.org/svn/deegree/deegree3/core/trunk/src/org/deegree/geometry/SimpleGeometryFactory.java">https://svn.wald.intevation.org/svn/deegree/deegree3/core/trunk/src/org/deegree/geometry/SimpleGeometryFactory.java</a><br><br>and one for those who need all the complex stuff<br><br>- <a href="https://svn.wald.intevation.org/svn/deegree/deegree3/core/trunk/src/org/deegree/geometry/GeometryFactory.java">https://svn.wald.intevation.org/svn/deegree/deegree3/core/trunk/src/org/deegree/geometry/GeometryFactory.java</a><font class="Apple-style-span" color="#006312"><br></font></div></blockquote></div><br><div>I really like the direction of different factories for different target communities. One thing we have moved to in the geotools code base is:</div><div>- the creation of a simple complete factory with no logic and no duplication</div><div>- 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</div><div><br></div><div>Jody</div></body></html>