There's a lot in common between ConvertLines,
ConvertNames, ConvertLinesZ (if implemented); and
perhaps ConvertPoints, ConvertDescriptors, and
ScanDescriptors. ConvertPolygons is a little different,
since it performs a topological build, but it also has a
few things in common with the others.
This leaves room for the common parts of these routines
to be refactored / hoisted into calls to common
subroutines or template functions.
Examples:
* All of these could call ReadDescriptor in a loop.
* The code to create or open a shapefile for output could
be refactored into a template.
* The long and double overloads of ReadLineVertices
could be refactored to delegate to a common template
(already done).
No doubt there's room for other refactorings, but these
are some of the most obvious.
Logged In: YES
user_id=533196
I started by changing ConvertDescriptors and
ScanDescriptors so they simply call ReadDescriptor in a loop.
This is checked into CVS, and seems to be working. The
convert functions that create shapefiles could get the same
treatment.
<p>
The NTXConverter class is a bit of a Blob. I flipped to a
procedural design once I had abstracted enough things that
it became easy / pragmatic to do it that way. But the code
would be cleaner and easier for others to work on if I had
stayed object-oriented throughout. However, in fixing this, it
is important to avoid breaking the VB function-call API.