Title: Message
|
Good
point about splitting the initial conditions out from the GeometryFactory.
I was trying to reduce the number of classes - but maybe that's somewhat less
flexible.
And
yes, this is all trivial in Java - I commiserate with you C++ guys....
8^)
I
would think smart pointers would help here. As for a default factory,
that probably makes a lot of sense for 98% of users - so seems like a good
idea.
Martin
Martin Davis, Senior Technical
Architect
Vivid Solutions
Inc.
www.vividsolutions.com
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250)
385 6040 - Local 308 Fax: (250) 385 6046
Thanks for the explanation Martin. Seems
like that is a workable design in Java, where the garbage collector worries
about freeing the factories for you when they are no longer referenced by any
geometries. I suppose I would probably split out the initial conditions
into some other object - so the factory just creates geometries. But in
the end, that doesn't change the issue I brought up.
So, in C++ Geos
could we use smart pointers to achieve the same effect? And maybe add in
a default global factory?
Charlie
Martin Davis wrote:
Those assumptions are correct.
There were two main reason for designing the GeometryFactory concept:
1) Provide a convenient, single location for defining the various "initial conditions" for Geometries. This includes the Precision Model, the CoordinateSequenceFactory, and sometimes the SRID. It may be extended in the future to contain things like which Polygon model to use, and preferences for precision handling.
2) Reduce the memory overhead of Geometries by moving relatively static objects (references) out of the Geometry and into a single shared object.
Hopefully this makes sense... But if anyone has good opinions about another design pattern, send them along.
Martin Davis, Senior Technical Architect
Vivid Solutions Inc. www.vividsolutions.com
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
Mateusz Loskot
Sent: March 30, 2006 5:10 PM
To: GEOS Development List
Subject: [geos-devel] GeometryFactory - call for explanation
Hi,
Could anyone explain/confirm me assumptions behind
the GeometryFactory class?
Depending on its semantic I'd have some proposal to refactor
it. Here are my qusetions:
Are following assumptions correct?
1. Ever instance of Geometry type (or its subtype) can have
assigned its own instance of GeometryFactory
2. One instance of GeometryFactory class can be shared
(assigned to) between more than one objects of Geometry class
3. It is not assumed that all geometries share the same
common instance of GeometryFactory
Thanks in advance for comments
Cheers
--
Mateusz Łoskot
http://mateusz.loskot.net
_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
|
_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
