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

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?

-
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

## 1 Answer

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.

-
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