Re: [Rails-devel] Status of Tile & Map Code Integration

[Erik V. <eri...@hc...>]

I completely agree with John. Enforcing a particular hierarchical order in
which features appear would be too rigid. 

This could be loosened by creating interfaces like HasShares, HasTokens etc,
which dedicated (perhaps game-dependent) company classes could implement,
but that would lead to even more class (+interface) files.

Other considerations:
1. Coding is easier the way it is: you only need tests like hasSharePrice()
etc. Your way you will get a lot of instanceof's + casts + separate
variables for the casted subtypes, to handle all the differences in (for
instance) OperatingRound.

2. We have enough classes as it is. I'm only in favour of creating new ones
if there is a real need for it, which I don't see in this case. I don't want
to spend too much time and energy in remembering small differences between
similar classes.
Systems are the only special types for which I see a need for a new class.
And maybe the 1841 concessions (but these are more like privates). 

3. Yes, PublicCompany is a large class. I'm sure there are some redundancies
and methods that belong somewhere else (similar to the redundant method in
Tile that we have spotted recently). But in handling company objects in
OperatingRound etc., the similarities between the various types look more
important to me than the differences.

On transformations: critical to me is whether or not the company name
changes. If so, it is a new company and shares are exchanged. If not (for
instance, when a minor or 5-share company transforms to a major or 10-share
company, as in 1826 and several other games), it remains the same company,
and shares are moved from "unavailable" to whereever the new shares are to
be put, and the percentage per share is changed (e.g. from 20 to 10).

Erik.


> -----Original Message-----
> From: John A. Tamplin [mailto:ja...@ja...] 
> Sent: Monday 10 November 2008 07:45
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Status of Tile & Map Code Integration
> 
> Mark Smith wrote:
> > When I came up with my hierarchy I was primarily focused on 
> the games
> > I currently own (1829, 1830, 1835, 1837, 1853, 1856, 1870). 
> And since
> > then many more sprang up. I do still feel building a basic hierarchy
> > for companies makes sense. It allows separation of 
> functionality. and
> > allows the class hierarchy enforce some of the game mechanics (a
> > company that is just a Train Company, cannot manipulate 
> tokens, and if
> > a Company is a Token Company, but not a Share Company cannot have
> > certificates that have variable price). But I would be interested in
> > what Brett & Erik have to say on the subject. I am sure they have
> > discussed this in the past.
> >   
> The problem is there are a large number of variations and 
> more will be 
> added over time.  Assume you have n different criteria you want to 
> encode in the class hierarchy (exists on the map, has tokens, has a 
> share price, may merge, etc).  If you encode all 
> possibilities into the 
> hierarchy, you wind up with n^m classes, most of which are very 
> similar.  If instead you expose these different functions 
> into separate 
> classes and have the company delegate to them depending on 
> what form it 
> currently has, you have only n*m classes with no code duplication.
> 
> Again think of the idea of Rails being to core code to implement any 
> game and the per-game files would contain only unique code needed for 
> that game.  If a new game requires a new combination of these 
> features 
> in a company, the only option would be to duplicate lots of in-Rails 
> code in the game-specific classes, which worsens the 
> maintenance burden 
> especially when they may have separate maintainers.
> 
> --
> John A. Tamplin					ja...@ja...
> 770/436-5387 HOME				4116 Manson Ave
>                 		 		Smyrna, GA  30082-3723
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>