Re: [Rails-devel] Stock market revisited

[Brett L. <wak...@ea...>]

>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.

Try to go with the model/view design approach.

For testability, toString() for the company markers on the stockmarket=
 should be defined to return 
their current position on the stockmarket. Returning a string that includes=
 position, value, and color 
is optional, but ideal.

Being able to craft some quick test cases for moving the marker around and=
 checking the results via console 
is the first end-goal for the stockmarket class.

I'll try to turn my swing demo into a more useful class that actually makes=
 use of the stockmarket objects.


>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.

As was mentioned before, linear is just rectangular with a single row. No=
 special class needed there.

>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 wouldn't focus too much on getting a hexagonal stockmarket working just=
 yet. So long as the generic class is 
capable of allowing implementation of these later, that's fine.

Because the standard rectangular markets are the most common, that should=
 be the focus of our current efforts and the first thing we get working.

>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.


I agree. The naming is ambiguous.


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


That's fine. I think the expectation from the beginning was that the XML=
 was to be game-specific.


>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.


Yes.  Though, I'd call it StockMarketHexagonal.  I hesitate to reference=
 specific games 
within the class and method naming.


>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?


I wouldn't set the priority on doing this very high. We can always change=
 it later.
My primary concern is getting a working stockmarket. 



---Brett.