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