Can a common interface be defined for Cartesian and Polar coordinate data?

Question

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?

Answer 1

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.