inverse OOP

[Martin Vales]

Hi:

I have always had a doubt about OOP.
Usually we have a parent and several child, but what happen if we need
the inverse system. for example DBI/DBD APIs.??

I need build map proyections and i want and intermediate API for all
proyections clases.

All map proyections have the same methods (geodetic_to_projected and
projected_to_geodetic)



Regards.

 

[Eleanor McHugh]

Hi:

I have always had a doubt about OOP.
Usually we have a parent and several child, but what happen if we need
the inverse system. for example DBI/DBD APIs.??

I need build map proyections and i want and intermediate API for all
proyections clases.

All map proyections have the same methods (geodetic_to_projected and
projected_to_geodetic)

Then define either a projection class from which they all inherit, or
a projection module which they all include.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Robert Klemme]

On 24 Apr 2008, at 10:40, Martin Vales wrote:

What exactly do you mean by "intermediate"? Do you mean that all
projections should have the same interface? For that you do not need
inheritance at all - at least in Ruby. Or do you rather mean that they
share behavior (implementation)?

Then define either a projection class from which they all inherit, or
a projection module which they all include.

Nice reading from you again, Ellie.

I was going to also suggest the module approach. But I do wonder why
Martin chose to call it "inverse OOP". It seems the more appropriate
term would be "multiple inheritance" or am I missing something?

Cheers

robert

 

[Martin Vales]

What exactly do you mean by "intermediate"? Do you mean that all
projections should have the same interface? For that you do not need
inheritance at all - at least in Ruby. Or do you rather mean that they
share behavior (implementation)?

Same interface:

For example


This is the intermediate API
#type="projection=lambert, varphi_0=45, k=1"
type="projection=UTM, zone=30, false_east=40000"
prj=Projection.new(type)

[x,y]=prj.geodetic_to_projected(lambda,phi)
[lambda,phi]=prj.projected_to_geodetic(x,y)


This is an especific API for UTM:

parameters=UtmParameters.new
parameters.zone=30
parameters.false_east=30
prj=UtmProjection.new(parameters)

[x,y]=prj.utm_geodetic_to_projected(lambda,phi)
[lambda,phi]=prj.utm_projected_to_geodetic(x,y)

This is an especific API for lambert:

parameters=LambertParameters.new
parameters.varphi_0=30
parameters.k=1
prj=LambertProjection.new(parameters)

[x,y]=prj.lambert_geodetic_to_projected(lambda,phi)
[lambda,phi]=prj.lambert_projected_to_geodetic(x,y)



I have used the proj.4 C library and they used pointers to functions in
C, in a offuscated code.

http://proj.maptools.org/

proj.4 use a text file like this:
"projection=lambert, varphi_0=45, k=1"

Every projection is an module (ANSI C file) and a only modulo know what
module call using the text file. There are 170 different projections.

+proj=cea +lon_0=Central Meridian
+lat_ts=Standard Parallel
+x_0=False Easting
+y_0=False Northing


+proj=lcc +lat_1=Latitude of natural origin
+lon_0=Longitude of natural origin
+k_0=Scale factor at natural origin
+x_0=False Origin Easting
+y_0=False Origin Northing

+proj=tmerc +lat_0=Latitude of natural origin
+lon_0=Longitude of natural origin
+k=Scale factor at natural origin
+x_0=False Easting
+y_0=False Northing


...

I was going to also suggest the module approach. But I do wonder why
Martin chose to call it "inverse OOP". It seems the more appropriate
term would be "multiple inheritance" or am I missing something?

Okay. then this is a multiple inheritance problem??

 

[Florian Gilcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi:

I have always had a doubt about OOP.
Usually we have a parent and several child, but what happen if we need
the inverse system. for example DBI/DBD APIs.??

Actually, thats quite a common problem of thought, because inheritance
is often considered
as _the_ problem solver in OOP. But that is not the case. I for my
part seldomly inherit.

The core feature of OOP is composition. So even without modules, you
could just implement
a class that has a certain set of features and hands everything else
to a class that has a
concrete implementation for that task (delegation, btw. ).
Depending on the language, this can get large because of the vast
amount of
boilerplate code you have to write for the delegating methods, but in
Ruby, this is a simple task.


Regards,
Florian Gilcher
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgRHZ8ACgkQJA/zY0IIRZbPZgCgp/Vx54NYWH6PppPXRENXic3s
OwEAn2SFwl0BnIJsu+fvc4+RUBlUGbn/
=tD69
-----END PGP SIGNATURE-----

 

[Eleanor McHugh]

What exactly do you mean by "intermediate"? Do you mean that all
projections should have the same interface? For that you do not
need inheritance at all - at least in Ruby. Or do you rather mean
that they share behavior (implementation)?

And if these functions are included from a module their names should
be to_projected and to_geodetic as it doesn't matter to other classes
what they're being translated from.

Nice reading from you again, Ellie.

Damn, I've gone and blown my anonymity again

I was going to also suggest the module approach. But I do wonder
why Martin chose to call it "inverse OOP". It seems the more
appropriate term would be "multiple inheritance" or am I missing
something?

That was my reaction. I did a lot of similar work many years ago when
I was a VB hacker and abstracted projections using interfaces, which
are marginally similar to Ruby's modules, but it's possible Martin has
some more complicated use case in mind.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Eleanor McHugh]

Okay. then this is a multiple inheritance problem??

I hate telling other people how to code, but yes it looks very much
like a multiple inheritance problem.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Robert Klemme]

I hate telling other people how to code, but yes it looks very much
like a multiple inheritance problem.

In fact, wasn't that exactly what Martin mentioned in his first posting:
a class that inherits from multiple parents? So basically MI is just
the name for what he described in the first place.

Kind regards

robert

 

[Martin Vales]

Thanks all hehe