[geos-devel] GeometryFactory - call for explanation

[Martin Davis]

Notice I said "*relatively* static".  You still need the flexibility to use different Precision Models and difference CoordinateSequence implementations when required.  I would think that a static default factory with a FLOATING PM and the default CS would be handy, though.

As for smart pointers, seems like a good idea - although being a Java guy now I have happily purged all of this kind of knowledge from my brain   8^) 

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: geos-devel-bounces at geos.refractions.net 
> [mailto:geos-devel-bounces at geos.refractions.net] On Behalf Of 
> Mateusz Loskot
> Sent: March 30, 2006 5:45 PM
> To: GEOS Development List
> Subject: Re: [geos-devel] GeometryFactory - call for explanation
> 
> 
> 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.
> 
> Yes, that's what factory pattern is for.
> 
> > 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.
> 
> I'd like ask question related to the second point.
> 
> Do you mean that another option would be to create one single 
> (global?) and shared factory?
> 
> If you do, then I'd say this stays in opposition to the 
> assumption nr 3:
> 
> "3. It is not assumed that all geometries share the same 
> common instance of GeometryFactory"
> 
> 
> We, with Sandro, are considering possible improvements 
> related to managing and track lifetime of object like those 
> factories. So, if my 3 assumptions I presented are correct, 
> and they are as you've confirmed already, then here is my proposal:
> 
> I'd suggest to use "Shared Smart Pointer" semantic to manage 
> geometry factories and their relations to geometry objects. 
> One possibility is to use boost::shared_ptr (no linking to 
> ext. libs required, just including one header, as <vector> or <list>).
> 
> Why?
> 
> 1. Using shared_ptr we don't have to track which factory is 
> assigned to which geometry.
> 
> 2. Using shared_ptr we don't have to track where is 
> particular factory used.
> 
> 3. Using shared_ptr it is guaranteed that GeometryFactory 
> object lives as long as it is required and no longer.
> 
> Why not to use singleton or when to use it?
> 
> Singleton is another option but *does* *not* apply to the 
> current design, according to assumptions already confirmed.
> 
> There is rationale to implement GeometryFactory as a 
> Singleton *only* if it is assumed that there is only *one* 
> factory and it is common to all instances of Geometry class. 
> But this situation does not occur as I understand (and 3 
> assumptions confirm).
> 
> strk:
> How are you convinced to move to smart pointers?
> 
> Cheers
> -- 
> Mateusz Łoskot
> http://mateusz.loskot.net 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net 
> http://geos.refractions.net/mailman/listinfo/geos-devel
>