Re: [Rails-devel] Train management

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

> -----Oorspronkelijk bericht-----
> Van: Stefan Frey [mailto:ste...@we...]


> My proposal would be not to subclass the train class, but to implement the
> trainI interface: The FlipTrain or MultiTrain class uses a state pattern,
which
> keeps a list of possible normal Trains it can change to and mainly
forwards the
> calls to the current active one.

Sounds good, except that we then still must create and somewhere hold a
current active train object. 

Perhaps the following refinement would even further simplify matters:

Currently the Train objects hold their own copy of (most of) the fixed
TrainType attributes, such as the number of stops.
That's actually redundant, we could as well pass on the calls for those
attributes to the corresponding TrainType. 
The TrainI types then only need the (dynamic) state objects.

For the new DualTrain class, this opens up the possibility to replace the
'current active train' by a 'current active train type', so we don't need to
create any additional Train objects.  I think this still can be a Train
subclass.

The main catch I then see is one of naming: we'll still need to distinguish
a buyable certificate-style name (such as "2/1G"), to be used at initial
buying time, and the actual train name, to be used everywhere else. That
seems to be a much less drastic change to me than my original
TrainCertificate proposal.

Erik