RE: [Rails-devel] RE: Revised Domain Object Model

[Stewart T. <wsr...@ho...>]

>
> > The revenue generated by a city can also be held as a
> > property of the tile - just as it is in the physical game set.
>
>Disagree.
>
>_City_ should be an object itself with a property _revenue_.
>
>The tile contains an array of these _city_-objects (max. 6: London
>1829/25?) and each _city_ has to be related to the _connections_ the
>tile provides.
>As you can see on tile #37 (1829 1825R1/R2) there is one connection
>going through without hitting a city and there are two connections
>ending up in a city.
>
>Another property could be an array of stations, each capable of
>holding 1 company-token. If all stations are filled, the city is
>blocked for other companies.

I believe that a flattened representation of cities and revenues in a Tile 
object can meet all of these requirements equally well. The combination of 
DisjointCityLocation and Tile can represent these relationships. The 
physical game system doesn't require separate cities from tiles, we should 
think carefully before deciding to represent cities as separate objects and 
be convinced that they will bring value to the software.

I agree that this is a denormalised view of the data involved, and many 
relational database designers would throw up their hands in horror at this 
failure to enforce 3rd normal form!

The track connectivity is an independent issue from the presence or absence 
of cities, and has to be solved for all tiles.

I think that tiles with large cities (those that can take tokens) have two 
orthogonal characteristics: 1) disjoint - where separate cities exist with 
different track connections, and possibly different revenues. 2) variable 
capacity - where there is just a single (conceptual) city that can take 
multiple tokens, but the connectivity is the same for each token. IIRC, 1837 
has a couple of tiles that combine both characteristics. That is, a tile 
where there are disjoint cities with a capacity greater than one token.

Stewart