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

[John A. T. <ja...@ja...>]

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