Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm rewriting a set of file readers that a former-colleague of mine created that read raw-point data of XYZ (Cartesian) coordinates or RTZ (Polar) coordinates. Currently the data is stored directly in the reader, making everything rely on the state of those objects. I'd like to separate the reader from the collected data it reads by creating some data objects.

Each of the coordinate systems is nearly identical from a purely data-driven point of view.

Cartesian Coordinates
  X (List of doubles) 
  Y (List of doubles) 
  Z (Multidimensional array of doubles at [X,Y])

Polar Coordinates
  R (List of doubles)
  T (List of doubles)
  Z (Multidimensional array of doubles at [R,T])

I'm trying to determine if I can, in good conscience, define a common interface for both of these. The data is the same, even though what it represents is subtly different. Each has two opposing axes of a 3D coordinate system, and a table of Z values at various combinations of those axes. But an X coordinate doesn't necessarily map to R. And I'm not sure what I would call the properties on a common interface - Axis1, Axis2, and Z?

Or am I trying to consolidate something here that really needs to remain separate? Should there be a separate (albeit similar) interface for each data object representing coordinates from each system?

share|improve this question
    
You could pick one of the representations (e.g. Cartesian), only work in that representation, and provide e.g. a fromPolar factory method that converts to cartesian –  Ismail Badawi Jan 14 '13 at 17:46
    
Hal Abelson of SICP fame uses exactly this example in his video lecture on Generic Operators. I suggest to everyone to watch this gem of CS education. –  pillmuncher Jan 15 '13 at 2:01
add comment

1 Answer

up vote 8 down vote accepted

You can convert from one coordinate to another. So you could choose to work internally with only one representation and create methods to get either representation from your class (i.e. getX, getY, getR, and getT) along with functions like rotate.

The problem with doing that, however, is that converting between coordinate systems is relatively expensive. If you have an application that needs to deal with polar coordinates while your class operates using Cartesian coordinates, you could easily chew up a bunch of CPU constantly converting back and forth. For many applications, that's not a performance hit that would be acceptable.

Personally, I would tend to prefer a Coordinate type with PolarCoordinate and CartesianCoordinate subtypes. Some operations like rotate would be more efficient when using the PolarCoordinate class while other operations like move would be more efficient when using the CartesianCoordinate class but you wouldn't incur the overhead of constantly converting between coordinate systems and your application could choose whichever representation would likely be more efficient for whatever tasks it was going to do.

share|improve this answer
    
I generally like the idea. At the moment it's not necessary to convert between them, but some day it may be, so I think I'll go with something like this. –  KChaloux Jan 14 '13 at 18:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.