[geos-devel] GeometryFactory - call for explanation

[Martin Davis]

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

	-----Original Message-----
	From: geos-devel-bounces at geos.refractions.net [mailto:geos-devel-bounces at geos.refractions.net] On Behalf Of Charlie Savage
	Sent: March 30, 2006 5:41 PM
	To: GEOS Development List
	Subject: Re: [geos-devel] GeometryFactory - call for explanation
	
	
	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: 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: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 at geos.refractions.net 
			http://geos.refractions.net/mailman/listinfo/geos-devel
			
			    

		_______________________________________________
		geos-devel mailing list
		geos-devel at geos.refractions.net
		http://geos.refractions.net/mailman/listinfo/geos-devel
		
		
		  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20060330/d41429b3/attachment.html