Re: [Rails-devel] Train management

[Stefan F. <ste...@we...>]

Erik:
you are right: we already have a dual structure with train and trainType, 
where train represents certificate and trainType the actual train attributes.

I agree with your proposal and would even suggest to remove the following 
attributes from the train class:

    protected int majorStops;
    protected int minorStops;
    protected int cost;
    protected int cityScoreFactor;
    protected int townScoreFactor;
    protected int townCountIndicator;
    
Instead any request to train for this should be forwarded from train to the 
traintype.

Then the train class would represent the standard train certificate which only 
references one traintype and a flipTrain that can have several potential 
trainTypes plus a current one (which could be null as long as it is not 
defined).

If you have flipTrain subclassing Train or have both be implementations of the 
interface trainI is up to you. However I prefer the latter and trainI is an 
unnecessary, as imho there is no need for an interface with only one 
implementation (unless you provide an official API).

Stefan 


On Monday, June 13, 2011 01:58:18 pm Erik Vos wrote:
> > -----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
> 
> 
> ---------------------------------------------------------------------------
> --- EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel