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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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@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
