[Rails-devel] Revised Domain Object Model

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

Hi,

Attached is a revised version of the object model, adjusted in light of 
comments. The main changes are as follows:

1) I've collapsed all of the companies into a single class, including the 
private companies. While there is some consensus that there is nothing 
intrinsically different between major and minor companies, rolling up 
private companies as well is a little more contentious. It's not just a case 
of allowing for all of the current 18xx variations in companies, but also 
trying to make some allowance for the unknown variations yet to be 
published.

A single class means that the assorted company behaviours have to be 
constrained with rules.

2) As promised, I've thought more about the issues of representing tiles 
with multiple and different cities. It is my belief that cities can be 
adequately represented as properties of the Tile classes. Having consulted 
my copy of 1856, it is only small cities (aka towns) that can be 
"downgraded" into straight track, so there is no interference with the 
location of a token in this process. 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.

However, there does have to be a way to associate a company's token with a 
specific large city on a tile that contain multiple large cities, if this 
cities are disjoint and have different revenue values or track connections. 
To enable this I've added a subclass of Location called 
DisjointCityLocation. I envisage most objects being directly of class 
Location, with only the few special cases being of DisjointCityLocation.

In this object model, I am trying to address those objects that need to be 
persistent in a saved game state. While cities are important for revenue 
calculation - that is a transient activity that does not need to be saved in 
the game state. Similarly, the behaviour of a specific train type is also 
important during revenue calculation, but as long as the behaviour is 
configured by a game specific rule set, and available to the revenue 
calculation algorithm, then there is no need to transform the Train class 
into a hierarchy of different types.

cheers

Stewart