[Rails-devel] Stock market revisited

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

Coming weekend I expect to have time to churn out some more
or some better code, and I would like (this time for once)
to submit my plan for review.

Let me start by expressing my appreciation for the positive
and fruitful way in which the discussions are held here.
I hope the below may also show that we really are making progress.

Although I could do many things (including buying a Swing book
and see how to make a stand-alone UI for the StockMarket
rather than my current servlet) I prefer to first redo the low-level
stuff I've done before, and perhaps add some functionality,
taking into account all the lessons I've learned so far.
Apologies to the servlet-runner-deprived.

First some considerations:

1. In theory we might be able to make one StockMarket class that can
handle all varieties (linear, rectangular and hexagonal)
but I think we can better split up into generic and special classes.

Hexagonal is rare (I believe 1837 only) so it's special anyway.
We might also consider linear stockmarkets special, because
so few games have it (AFAIK only the Tresham games and 1860).

I'm not sure yet if we need an abstract superclass, 
or just a generic one with built-in handling of rectangular
stockmarkets; we'll see. (Yes, I will mention interfaces below).

2. StockMarket is a singleton and should IMO be constructed as such.
This means: private constructors, access only via a static get()
method that returns the one instance (which is created the first time,
or from a static init block).
In addition to safety, this removes the need to pass around object
variables,
as each class needing access to the stockmarket object can get it 
immediately by calling StockMarket.get().

3. The single instance generated will be of a type defined in the XML
config file.
That class will then be instantiated by a class factory
(not sure how classloaders work in a stand-alone program - on this
aspect I have worked with servlets under Tomcat only: a nightmare, but
finally solved).

4. The return type of the get() should obviously be an interface type.

5. The above applies both to StockMarket and StockChart.
In hindsight I think splitting these was not a very good idea,
because we might end up duplicating the whole class/interface structure.

6. Special subclasses might need additional or different XML entries.
I suppose that the XML DTD may become game-specific too in some cases.

The plan:

1. Recombine StockMarket and StockChart. Some or all StockChart methods
become private.

2. Create an interface named StockMarket, defining the same methods 
that we now have in the same-named class.

3. Create a base implementation class StockMarketGeneric, handling
rectangular markets.
This class will have the methods currently in StockMarket and StockChart.
Later on we can write subclasses like StockMarketLinear, StockMarket1837
and perhaps other ones, that will override methods like payOut() 
and can contain any special stuff.

3. The XML stockmarket opening tag will define the 
class to be instantiated, like <stockmarket class="StockMarketLinear">,
the default being StockMarketGeneric.

4. If I have time, _and_ get good advice on a replacement, I might replace
the SAX parser.
I'm somewhat concerned, though, that we will end up having the XML file
contents
in memory twice: once in the DOM object, and once in the class attributes
(organised as suits the class best). Is this a valid concern?

Enough for today. Have fun.

Erik.