Re: [Rails-devel] Train management

[brett l. <bre...@gm...>]

On Fri, Jun 10, 2011 at 3:02 AM, Erik Vos <eri...@xs...> wrote:
>> -----Oorspronkelijk bericht-----
>> Van: Phil Davies [mailto:de...@gm...]
>>
>> On 9 June 2011 22:34, John David Galt <jd...@di...>
>> wrote:
>> >   But there is no reason ever to create a "train certificate" object,
>> > because the type of a train becomes fixed in stone as soon as it is
>> > first acquired by a company.  I don't know of an exception to this in
> any
>> game.
>>
>> Erik already mentioned above but in 18VA, if a train gets discarded to the
>> pool it reverts to being a certificate and the new purchaser can choose
> which
>> type of train it is.
>
> Indeed. In any case we need some kind of object that joins the two train
> types.
>
> Another approach that I'm considering is a new train subclass named
> DualTrain. This type would behave as a train if owned by a company, and as a
> dual train certificate if owned by the Bank.
> The upside is, that I suspect less changes are needed to the train handling
> code, but the downsides are (1) a higher chance to overlook certain required
> changes, and (2) we still don't have a solution for 18GA, for which we
> really need a different (or additional) way to create trains.
> Still this approach might turn out to be the easiest one.  The jury is out.
>
> Erik.
>

I support your initial proposal. It makes sense to have a base
class/interface used for creating as many sub-classes as are needed to
describe all of the various variations on "Train".

We already do this with just about every other concept. Hex,
Certificate, StockMarket, etc. etc. etc.

I'd much rather have a clear class hierarchy. The primary benefit will
be readable, understandable code rather than a set of sub-classes that
makes everyone ask, "Why is it done this way?"

---Brett.