473,324 Members | 1,856 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

A little O-O design pattern question...

I'm curious to see if anyone has an opinion on this little design question -

I'm doing a computational astronomy library in C#, purely for my own use,
and one of the things that happens regularly is conversion of coordinates
from one frame of reference to another: spherical coordinates in the
ecliptic frame of reference, spherical coordinates in the equatorial frame
of reference, 3D rectangular coordinates in either, galactic coordinates,
horizontal coordinates, and on and on. The question relates to where to site
the conversion methods most naturally.

To illustrate the question, I've boiled it down to a simple case:

Consider 2D plane coordinates: you have Cartesian (rectangular) coordinates
(X and Y) and polar coordinates (angle and radius vector). The
transformations between them are well-known and simple. So you can take
rectangular coordinates (a subclass of Point, perhaps, named
CartesianCoords), apply the transformation to X and Y, and get out polar
coordinates. And vice versa.

So where do the conversion methods best reside? Here are some
possibilities:

1. A static conversion function such as CartesianToPolar(CartesianCoords cc)
returning a PolarCoordinates object;

2. An instance method on a CartesianCoords object returning a
PolarCoordinates object;

3. A PolarCoordinates constructor taking a CartesianCoords object, which
applies the conversion and populates its data members from the outcome of
the transformation.

Admittedly this is a fairly minor point, for the example above, but when you
have a half-dozen different coordinate systems, with potential conversions
between all pairs, there's a combinatorial explosion that might get ugly.
Also, while the transformation described above needs no other information
besides the coordinates, some of the astronomical transformations require
additional parameters.

Any thoughts?

Or if you don't think this is the right place to post a question like this,
how about a suggestion for a more appropriate newsgroup or site (I didn't
find a real natural venue in a quick search of the newsgroup names)?

Thanks,
Tom Dacon
Dacon Software Consulting

Nov 20 '05 #1
9 1322
I would suggest writing a class for each kind of coordinate, and then add
conversion operators between the ones that are equivalent.

So, that would allow you to specify a method taking PolarCoordinate, and if
the user passed a CartesianCoordinate, it would be converted automatically.

For the ones that take parameters, I think you'll want to define
constructors that take the coordinate and the additional parameters.

"Tom Dacon" <To**@t-dacons.com> wrote in message
news:O4**************@TK2MSFTNGP09.phx.gbl...
I'm curious to see if anyone has an opinion on this little design question -
I'm doing a computational astronomy library in C#, purely for my own use,
and one of the things that happens regularly is conversion of coordinates
from one frame of reference to another: spherical coordinates in the
ecliptic frame of reference, spherical coordinates in the equatorial frame
of reference, 3D rectangular coordinates in either, galactic coordinates,
horizontal coordinates, and on and on. The question relates to where to site the conversion methods most naturally.

To illustrate the question, I've boiled it down to a simple case:

Consider 2D plane coordinates: you have Cartesian (rectangular) coordinates (X and Y) and polar coordinates (angle and radius vector). The
transformations between them are well-known and simple. So you can take
rectangular coordinates (a subclass of Point, perhaps, named
CartesianCoords), apply the transformation to X and Y, and get out polar
coordinates. And vice versa.

So where do the conversion methods best reside? Here are some
possibilities:

1. A static conversion function such as CartesianToPolar(CartesianCoords cc) returning a PolarCoordinates object;

2. An instance method on a CartesianCoords object returning a
PolarCoordinates object;

3. A PolarCoordinates constructor taking a CartesianCoords object, which
applies the conversion and populates its data members from the outcome of
the transformation.

Admittedly this is a fairly minor point, for the example above, but when you have a half-dozen different coordinate systems, with potential conversions
between all pairs, there's a combinatorial explosion that might get ugly.
Also, while the transformation described above needs no other information
besides the coordinates, some of the astronomical transformations require
additional parameters.

Any thoughts?

Or if you don't think this is the right place to post a question like this, how about a suggestion for a more appropriate newsgroup or site (I didn't
find a real natural venue in a quick search of the newsgroup names)?

Thanks,
Tom Dacon
Dacon Software Consulting


Nov 20 '05 #2
From reading it, I think a shared [static] method may be in your best
interests especially if you don't need to reference anything in particular.

You could create a base class to inherit off of, but I don't know if you
really need to, unless there is a clear heirarchy between the two.

But simply build a external library (like your doing, create a class called
computations and add shared methods to do your dirty work... But I dont'
see a real need for object inheritance at this point, maybe I'm wrong.

Hope it helps.

-CJ
"Tom Dacon" <To**@t-dacons.com> wrote in message
news:O4**************@TK2MSFTNGP09.phx.gbl...
I'm curious to see if anyone has an opinion on this little design question -
I'm doing a computational astronomy library in C#, purely for my own use,
and one of the things that happens regularly is conversion of coordinates
from one frame of reference to another: spherical coordinates in the
ecliptic frame of reference, spherical coordinates in the equatorial frame
of reference, 3D rectangular coordinates in either, galactic coordinates,
horizontal coordinates, and on and on. The question relates to where to site the conversion methods most naturally.

To illustrate the question, I've boiled it down to a simple case:

Consider 2D plane coordinates: you have Cartesian (rectangular) coordinates (X and Y) and polar coordinates (angle and radius vector). The
transformations between them are well-known and simple. So you can take
rectangular coordinates (a subclass of Point, perhaps, named
CartesianCoords), apply the transformation to X and Y, and get out polar
coordinates. And vice versa.

So where do the conversion methods best reside? Here are some
possibilities:

1. A static conversion function such as CartesianToPolar(CartesianCoords cc) returning a PolarCoordinates object;

2. An instance method on a CartesianCoords object returning a
PolarCoordinates object;

3. A PolarCoordinates constructor taking a CartesianCoords object, which
applies the conversion and populates its data members from the outcome of
the transformation.

Admittedly this is a fairly minor point, for the example above, but when you have a half-dozen different coordinate systems, with potential conversions
between all pairs, there's a combinatorial explosion that might get ugly.
Also, while the transformation described above needs no other information
besides the coordinates, some of the astronomical transformations require
additional parameters.

Any thoughts?

Or if you don't think this is the right place to post a question like this, how about a suggestion for a more appropriate newsgroup or site (I didn't
find a real natural venue in a quick search of the newsgroup names)?

Thanks,
Tom Dacon
Dacon Software Consulting


Nov 20 '05 #3
Hi Tom,

Why do not take note of the way the framework itself handle a similar
situation, It provide a Convert class that deal with converting from one
basic type to other, if you see this class is similar to what you want. It
has for example ToDecimal that return a decimal struct and has one version
for each of the types in the CLR, you could do the same, create a class
CoordinateConvert that define a method like ToCartesian overloaded as
needed:

CartesianClass ToCartesian( SphericClass o);
CartesianClass ToCartesian( GalacticClass o);
CartesianClass ToCartesian( EclipticClass o);

Hope this help,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Tom Dacon" <To**@t-dacons.com> wrote in message
news:O4**************@TK2MSFTNGP09.phx.gbl...
I'm curious to see if anyone has an opinion on this little design question -
I'm doing a computational astronomy library in C#, purely for my own use,
and one of the things that happens regularly is conversion of coordinates
from one frame of reference to another: spherical coordinates in the
ecliptic frame of reference, spherical coordinates in the equatorial frame
of reference, 3D rectangular coordinates in either, galactic coordinates,
horizontal coordinates, and on and on. The question relates to where to site the conversion methods most naturally.

To illustrate the question, I've boiled it down to a simple case:

Consider 2D plane coordinates: you have Cartesian (rectangular) coordinates (X and Y) and polar coordinates (angle and radius vector). The
transformations between them are well-known and simple. So you can take
rectangular coordinates (a subclass of Point, perhaps, named
CartesianCoords), apply the transformation to X and Y, and get out polar
coordinates. And vice versa.

So where do the conversion methods best reside? Here are some
possibilities:

1. A static conversion function such as CartesianToPolar(CartesianCoords cc) returning a PolarCoordinates object;

2. An instance method on a CartesianCoords object returning a
PolarCoordinates object;

3. A PolarCoordinates constructor taking a CartesianCoords object, which
applies the conversion and populates its data members from the outcome of
the transformation.

Admittedly this is a fairly minor point, for the example above, but when you have a half-dozen different coordinate systems, with potential conversions
between all pairs, there's a combinatorial explosion that might get ugly.
Also, while the transformation described above needs no other information
besides the coordinates, some of the astronomical transformations require
additional parameters.

Any thoughts?

Or if you don't think this is the right place to post a question like this, how about a suggestion for a more appropriate newsgroup or site (I didn't
find a real natural venue in a quick search of the newsgroup names)?

Thanks,
Tom Dacon
Dacon Software Consulting


Nov 20 '05 #4
Hi,

"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:uI**************@TK2MSFTNGP12.phx.gbl...
I would suggest writing a class for each kind of coordinate, and then add
conversion operators between the ones that are equivalent.

The problem I see with this is the difficult to maintain it. If tomorrow
you include a new coordinate you need to derive/change ALL the classes, in
other words the classes are tighly coupled ( not a good thing in OOP ) the
best idea is to keep all the possible conversion on a single class, in this
escenario if a new coordinate is added you only need to expand this class to
include the new overloaded method.
Hope this help,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Nov 20 '05 #5
Hi Tom,

I thought about this and then read the other replies and I'm posting as a
response to Ignacio.

With questions like these I think in terms of need-to-know (which I guess
is my vocabulary for tight-coupling). If a class doesn't need to know about
another in order to do its thing, why burden it? Especially when the
extraneous knowledge is two-way and the set of others gets bigger - that
explosion you mentioned. This suggests an intermediary - someone who knows
everyone in the set - a bit like an introduction agency, maybe. In other
words, Ignacio's CoordConverter.

There is a case for favourites, though - for the sake of convenience. For
instance, in .NET an Integer knows how to turn itself into a string and parse
itself from one. For completeness the CoordConverter would also provide that
conversion, of course, but for ease of programming it could simply get the
Coord to do the job.

To help cut down on your explosion, the Converter could do two-stage, and
maybe even three-stage, conversions, although you'd have to give accuracy and
computational cost at least a passing thought. Using this approach, I think
that the centralised nature of a Converter would be a boon.

Regards,
Fergus

ps. Small points can develop into principles. ;-)
Nov 20 '05 #6
On Fri, 3 Oct 2003 12:55:53 -0700, "Tom Dacon" <To**@t-dacons.com>
wrote:
I'm curious to see if anyone has an opinion on this little design question -


The most robust model is to use inheritance. The trick is to decide on
a "base co-ordinate system". All sub-classes need implement a
conversion to and from that base only.

A little VB code to demonstrate...

Public MustInherit Class BaseCoordinate

' This is the conversion function

Public Function SetValue(ByVal oValue As BaseCoordinate)
SetBaseCoordinateValue(oValue.GetBaseCoordinateVal ue())
End Function

' You might want to implement these as a property instead

Protected MustOverride Function GetBaseCoordinateValue() _
As BaseCoordinate

Protected MustOverride Function SetBaseCoordinateValue( _
ByVal oValue As BaseCoordinate) As BaseCoordinate

End Class

.... after which, casting is safe. Just plonk any old co-ordinate
system in as the value to SetValue() and the correct conversion
functions will be called.

By all means, implement a shared method to do actual conversion, but
it's nice to supply a constructor too.

Rgds,
Nov 20 '05 #7
Applying the principles of Design Patterns...

1. Program to an interface not an implementation.
2. Find out what is changing and abstract it.

You have different algorithms for converting. The Strategy Pattern might fit
into this. You have different classes for different type of conversions and
the context will give you appropriate algorithm based on the pre-defined
conditions.

I feel more elegant way of handling this might be with the help of Strategy
Pattern.

"Tom Dacon" <To**@t-dacons.com> wrote in message
news:O4**************@TK2MSFTNGP09.phx.gbl...
I'm curious to see if anyone has an opinion on this little design question -
I'm doing a computational astronomy library in C#, purely for my own use,
and one of the things that happens regularly is conversion of coordinates
from one frame of reference to another: spherical coordinates in the
ecliptic frame of reference, spherical coordinates in the equatorial frame
of reference, 3D rectangular coordinates in either, galactic coordinates,
horizontal coordinates, and on and on. The question relates to where to site the conversion methods most naturally.

To illustrate the question, I've boiled it down to a simple case:

Consider 2D plane coordinates: you have Cartesian (rectangular) coordinates (X and Y) and polar coordinates (angle and radius vector). The
transformations between them are well-known and simple. So you can take
rectangular coordinates (a subclass of Point, perhaps, named
CartesianCoords), apply the transformation to X and Y, and get out polar
coordinates. And vice versa.

So where do the conversion methods best reside? Here are some
possibilities:

1. A static conversion function such as CartesianToPolar(CartesianCoords cc) returning a PolarCoordinates object;

2. An instance method on a CartesianCoords object returning a
PolarCoordinates object;

3. A PolarCoordinates constructor taking a CartesianCoords object, which
applies the conversion and populates its data members from the outcome of
the transformation.

Admittedly this is a fairly minor point, for the example above, but when you have a half-dozen different coordinate systems, with potential conversions
between all pairs, there's a combinatorial explosion that might get ugly.
Also, while the transformation described above needs no other information
besides the coordinates, some of the astronomical transformations require
additional parameters.

Any thoughts?

Or if you don't think this is the right place to post a question like this, how about a suggestion for a more appropriate newsgroup or site (I didn't
find a real natural venue in a quick search of the newsgroup names)?

Thanks,
Tom Dacon
Dacon Software Consulting


Nov 20 '05 #8
I don't know if any of the responders are still watching this thread, but if
any of you are I'd like to thank you for your responses.

I've decided to go with a converter class with a set of static methods to do
the various conversions, in order to collect all the transforms in a single
place. For the most commonly-used conversions, I'll supply a little
syntactic sugar on some of the coordinate classes, either in constructors or
in function methods that output a transformed coordinate object. They
themselves will use the static methods, so as to keep the logic all in one
place.

I investigated the TypeConverter class as a mechanism for the conversions,
with a view toward using a pattern that's used by the framework itself, but
ultimately didn't go down that road. The problem is that some of the
conversions are parameterized and require externally-supplied bits of
information not already encapsulated in the coordinate object's state. So a
set of explicit static methods with overloads appears to be the way to go.

Thanks for taking the time to comment,

Tom Dacon
Dacon Software Consulting

"Tom Dacon" <To**@t-dacons.com> wrote in message
news:O4**************@TK2MSFTNGP09.phx.gbl...
I'm curious to see if anyone has an opinion on this little design question -
I'm doing a computational astronomy library in C#, purely for my own use,
and one of the things that happens regularly is conversion of coordinates
from one frame of reference to another: spherical coordinates in the
ecliptic frame of reference, spherical coordinates in the equatorial frame
of reference, 3D rectangular coordinates in either, galactic coordinates,
horizontal coordinates, and on and on. The question relates to where to site the conversion methods most naturally.

To illustrate the question, I've boiled it down to a simple case:

Consider 2D plane coordinates: you have Cartesian (rectangular) coordinates (X and Y) and polar coordinates (angle and radius vector). The
transformations between them are well-known and simple. So you can take
rectangular coordinates (a subclass of Point, perhaps, named
CartesianCoords), apply the transformation to X and Y, and get out polar
coordinates. And vice versa.

So where do the conversion methods best reside? Here are some
possibilities:

1. A static conversion function such as CartesianToPolar(CartesianCoords cc) returning a PolarCoordinates object;

2. An instance method on a CartesianCoords object returning a
PolarCoordinates object;

3. A PolarCoordinates constructor taking a CartesianCoords object, which
applies the conversion and populates its data members from the outcome of
the transformation.

Admittedly this is a fairly minor point, for the example above, but when you have a half-dozen different coordinate systems, with potential conversions
between all pairs, there's a combinatorial explosion that might get ugly.
Also, while the transformation described above needs no other information
besides the coordinates, some of the astronomical transformations require
additional parameters.

Any thoughts?

Or if you don't think this is the right place to post a question like this, how about a suggestion for a more appropriate newsgroup or site (I didn't
find a real natural venue in a quick search of the newsgroup names)?

Thanks,
Tom Dacon
Dacon Software Consulting


Nov 20 '05 #9
Hi Tom,

Way to go! ;-))

Regards,
Fergus
Nov 20 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
by: Tom Dacon | last post by:
I'm curious to see if anyone has an opinion on this little design question - I'm doing a computational astronomy library in C#, purely for my own use, and one of the things that happens regularly...
10
by: Saso Zagoranski | last post by:
hi, this is not actually a C# problem but since this is the only newsgroup I follow I decided to post my question here (please tell me where to post this next time if you think this post...
12
by: FluffyCat | last post by:
New on November 28, 2005 for www.FluffyCat.com PHP 5 Design Pattern Examples - the Visitor Pattern. In the Visitor pattern, one class calls a function in another class and passes an instance of...
22
by: Krivenok Dmitry | last post by:
Hello All! I am trying to implement my own Design Patterns Library. I have read the following documentation about Observer Pattern: 1) Design Patterns by GoF Classic description of Observer....
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.