City and Connection

[draq]

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?

 

[Robert Klemme]

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

 

[daz]

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

 

[Robert Klemme]

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

 

[draq]

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

 

[daz]

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

 

[daz]

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

 

[Robert Klemme]

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

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]

LOL

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

 

[Robert Klemme]

No offence committed ... I mean none taken )

No caffeine omitted ... I lean on bacon ;-)

Um, punish mood... I better shut up now.

robert

 

[Rob Rypka]

Yes; the relationship probably is one-way (Connection -> City)
i.e. a City shouldn't need to understand a Connection.

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.