E. g. I am going to make a programm for a forwarding agency containing
two classes: City and Connection.
The class City contains information about clients, goods etc. and the
class Connection implies the path length, potential toll charges and
type of the road.
How can I implement the two classes the best? With both classes
referring to each other?
draq wrote:
E. g. I am going to make a programm for a forwarding agency containing
two classes: City and Connection.The class City contains information about clients, goods etc. and the
class Connection implies the path length, potential toll charges and
type of the road.How can I implement the two classes the best? With both classes
referring to each other?
Well, a connection certainly needs a starting and ending point - at least
this seems most natural. Whether a city needs to know all its connections
depends on the application. With that little info hard to tell...
Kind regards
robert
draq wrote:
E. g. I am going to make a programm for a forwarding agency containing
two classes: City and Connection.The class City contains information about clients, goods etc. and the
class Connection implies the path length, potential toll charges and
type of the road.How can I implement the two classes the best? With both classes
referring to each other?
In my inexperience, I would inherit from a Map.
Fortunately for you, there are folks here who'll tell
us why this is an awful suggestion (?) 
class Map
Cities = Hash
def Map.add_city(name, latitude, longitude)
Cities[name] = City.new(name, latitude, longitude)
end
end
class City < Map
attr_reader :grid_ref, :name
def initialize(name, latitude, longitude, *rest)
@name = name
@grid_ref = [latitude, longitude]
end
end
class Connection < Map
attr_reader :conn1, :conn2, :distance
def initialize(name1, name2)
@conn1 = Cities[name1]
@conn2 = Cities[name2]
@distance = 'some calculation'
end
end
Map.add_city('Tokyo', 33, 11)
Map.add_city('Paris', 44, 22)
Map.add_city('Melbourne', 11, 88)
Map.add_city('New Delhi', 00, 77)
Map.add_city('Singapore', 55, 55)
c01 = Connection.new('Tokyo', 'Paris')
p [c01.conn1.name, c01.conn1.grid_ref] # ["Tokyo", [33, 11]]
(don't take this too seriously, yet)
daz
Fortunately for you, there are folks here who'll tell
us why this is an awful suggestion (?)
Because it's Bad, is's Bad-
Come On
(Bad Bad-Really, Really Bad)
You Know it's Bad, it's Bad-
You Know It
(Bad Bad-Really, Really Bad)
You Know it's Bad, it's Bad-
Come On, You Know
(Bad Bad-Really, Really Bad)
And The Whole World Has To
Answer Right Now
Just To Tell You Once Again,
What's Bad...
(to the melody of a (in)famous pop song)
(don't take this too seriously, yet)
Done.
SCNR :-))
robert
daz <dooby@d10.karoo.co.uk> wrote:
Thank you for your tip. Though I am not going to implement as you told
me, I appreciate the approach to use a class Map.
My thought is following:
class City without any references to the connections.
class Connection
@city1, @city2
end
class Map
map = Hash.new # key == city
# value == Array.new which contains the
connections referring to that city.
What do you think about this?
draq
draq wrote:
My thought is following:
class City without any references to the connections.
Yes; the relationship probably is one-way (Connection -> City)
i.e. a City shouldn't need to understand a Connection.
class Connection
@city1, @city2
end
It depends on what you consider the connection to be --
(City -> City) or (Client -> Client). A City must allow
for multiple Clients but WidgetCo may have distribution
points in multiple locations. It might make more sense
to have unique Client keys which would point to the City.
class Map
map = Hash.new # key == city
# value == Array.new which contains the
connections referring to that city.What do you think about this?
With conn3 as [city1, city7], you'd have:
city1 => [conn3, ...]
city7 => [..., conn3]
- which is duplication you might be able to avoid unless/until
performance suffers.
... connections.select {|conn| conn.include? this_city} ...
(sort of thing) - would find what you need.
What I mean is: a Hash search on city1 *and* city7 isn't possible,
so don't bother creating a structure that can't use it.
Use whatever "feedback" you can get from your design.
If the coding feels awkward, the design is weak ... if the
program starts writing itself, you're onto a winner.
The 7-minute template I gave would have been enough to identify
potential problems with data access.
Without background details, demonstrations often look "forced"
- so I'm very pleased you're not going to copy it verbatim
daz
Robert Klemme wrote:
daz wrote:
> Fortunately for you, there are folks here who'll tell
> us why this is an awful suggestion (?)[...]
Just To Tell You Once Again,
What's Bad...(to the melody of a (in)famous pop song)
SCNR :-))
robert
I have to resist commenting, else it's a court appearance for me
daz
LOL
Just to prevent misunderstandings: I didn't want to disregard what you wrote. It was just a silly reaction to your "invitation".
Kind regards
robert
daz <dooby@d10.karoo.co.uk> wrote:
Robert Klemme wrote:
daz wrote:
Fortunately for you, there are folks here who'll tell
us why this is an awful suggestion (?)[...]
Just To Tell You Once Again,
What's Bad...(to the melody of a (in)famous pop song)
SCNR :-))
robert
I have to resist commenting, else it's a court appearance for me
This sounds like straight-up graph theory. The graph representations
I've done in the past have always been deceptively simple.
Depending on the complexity of your data and the types of problems you
need to solve, you may want City to have a list of incoming and
outgoing connections. It saves time culling the edge/connection list
if you're computing shortest path, etc.
I could, of course, be way off, and you're free to ignore me.
On 11/1/05, daz <dooby@d10.karoo.co.uk> wrote:
draq wrote:
> My thought is following:
>
> class City without any references to the connections.
>Yes; the relationship probably is one-way (Connection -> City)
i.e. a City shouldn't need to understand a Connection.
--
Rob
Robert Klemme wrote:
daz wrote:
>
> I have to resist commenting, else it's a court appearance for meLOL
Just to prevent misunderstandings: I didn't want to disregard what you
wrote. It was just a silly reaction to your "invitation".
No offence committed ... I mean none taken ;))
daz
No caffeine omitted ... I lean on bacon
Um, punish mood... I better shut up now.
robert
daz <dooby@d10.karoo.co.uk> wrote:
No offence committed ... I mean none taken ;))