Re: [Rails-devel] Train management

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

On the train certificate vs. new train type:

I guess that the biggest disadvantage of the train certificate solution is the 
problem to keep certificates and trains combined correctly. 
On reload and especially undo/redo situations the certificates and trains have 
to be the identical objects for each transfer. Otherwise it can get a mess 
similar to situations that haunted/haunt transfer of share certificates. 

A robust solution would be to id both certificate and train, but this requires 
changing all actions that refer to the trains.

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. 

In addition it has some additional methods/attributes which define the 
behavior of the flip/state change.

From my point of view this would keep the number of changes to the overall 
code minimal and does not require to keep certificates and trains objects 
aligned all the time.

But as always there are pros and cons to every solution.

Stefan


On Friday, June 10, 2011 06:55:58 pm brett lentz wrote:
> 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.
> 
> ---------------------------------------------------------------------------
> --- 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