Menu
▾
▴
rails-devel
|
From: Iain A. <ia...@co...> - 2005-03-02 22:10:12
|
I suggested in a previous post using interfaces for primary datatype definitions: one example of how this is done can be found in the Java Collections framework. Here List is an interface which has a number of implementation classes, which differ in their internal representations: ArrayList LinkedList, etc. StockMarket.getIpoPile() has a return type of ArrayList - this class should be free to change its list representation without an API change, which can be achieved by declaring the method to return a List. Personally, I would also make the member variable ipoPile be type List, and initialise it as a 'new ArrayList()' in the first instance. Iain. |
|
From: Brett L. <wak...@ea...> - 2005-03-03 06:46:59
|
I think this is a good direction to take. Are you able to submit some code to move us in that direction? ---Brett. *********** REPLY SEPARATOR *********** On 3/2/2005 at 10:12 PM Iain Adams using ia...@co...= declared: >I suggested in a previous post using interfaces for primary datatype >definitions: one example of how this is done can be found in the Java >Collections framework. Here List is an interface which has a number of >implementation classes, which differ in their internal representations: >ArrayList LinkedList, etc. StockMarket.getIpoPile() has a return type of >ArrayList - this class should be free to change its list representation >without an API change, which can be achieved by declaring the method to >return a List. Personally, I would also make the member variable ipoPile= be >type List, and initialise it as a 'new ArrayList()' in the first instance. > >Iain. > > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick >_______________________________________________ >Rails-devel mailing list >Rai...@li... >https://lists.sourceforge.net/lists/listinfo/rails-devel ********** REPLY SEPARATOR END ********** This message sent with 100% recycled electrons. |
|
From: Stewart T. <wsr...@ho...> - 2005-03-03 11:26:14
|
Brett, If you regard all of the "classes" on the domain object model as being implemented as Java "interfaces", with a separate implementation class (or more than one!) then you'll be well on the way to achieving the independence suggested. In practical terms method parameters and returns for non simple data types are expressed with the Interface name rather than the Class name. Stewart >From: "Brett Lentz" <wak...@ea...> >Reply-To: rai...@li... >To: rai...@li... >Subject: Re: [Rails-devel] Java style point >Date: Wed, 02 Mar 2005 18:04:53 -0800 > >I think this is a good direction to take. > >Are you able to submit some code to move us in that direction? > > >---Brett. > >*********** REPLY SEPARATOR *********** > >On 3/2/2005 at 10:12 PM Iain Adams using ia...@co... >declared: > > >I suggested in a previous post using interfaces for primary datatype > >definitions: one example of how this is done can be found in the Java > >Collections framework. Here List is an interface which has a number of > >implementation classes, which differ in their internal representations: > >ArrayList LinkedList, etc. StockMarket.getIpoPile() has a return type of > >ArrayList - this class should be free to change its list representation > >without an API change, which can be achieved by declaring the method to > >return a List. Personally, I would also make the member variable ipoPile >be > >type List, and initialise it as a 'new ArrayList()' in the first >instance. > > > >Iain. > > > > > > > >------------------------------------------------------- > >SF email is sponsored by - The IT Product Guide > >Read honest & candid reviews on hundreds of IT Products from real users. > >Discover which products truly live up to the hype. Start reading now. > >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >_______________________________________________ > >Rails-devel mailing list > >Rai...@li... > >https://lists.sourceforge.net/lists/listinfo/rails-devel > > >********** REPLY SEPARATOR END ********** >This message sent with 100% recycled electrons. > > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_ide95&alloc_id396&op=click >_______________________________________________ >Rails-devel mailing list >Rai...@li... >https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@hc...> - 2005-03-03 21:07:25
|
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. |
|
From: Brett L. <wak...@ea...> - 2005-03-04 17:18:51
|
>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. |
|
From: Erik V. <eri...@hc...> - 2005-03-04 20:33:15
|
> 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. The StockChart moveXxxx() methods already write the moves to System.out, if that is what you want. (I guess this will later be replaced by writing to a log). > >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. I noticed that. The question still is (not just here but in general): how many different variants are we prepared to cram in one class? Maybe I have a tendency to subclass (too) early and (too) often... > >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. Sure, 1837 is a *very* long term goal (frankly I'm not convinced that we get even 1830 out of the door, but that does not depress me. It's a hobby!). Erik. |
|
From: Brett L. <wak...@ea...> - 2005-03-05 02:36:17
|
*********** REPLY SEPARATOR *********** On 3/4/2005 at 9:33 PM Erik Vos using eri...@hc... declared: >> 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. > >The StockChart moveXxxx() methods already write the moves to System.out, >if that is what you want. >(I guess this will later be replaced by writing to a log). > The reason I suggest using toString() is that this will allow us to use it= for many other things beyond simply testing the classes. For example, it's an easy way for us to gather reporting data about the= state of the game by using each objects toString() method rather than= polling every getFoo() method for every property within the object. >> >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. > >I noticed that. The question still is (not just here but in general): >how many different variants are we prepared to cram in one class? >Maybe I have a tendency to subclass (too) early and (too) often... > Well, it's something to take on a case-by-case basis. The big point is that in the case of linear markets, there's no need to do= the extra work of creating a whole new subclass because the normal= rectangular market will already work as a linear market without any= modifications. This project is going to be complex enough, so anywhere that we can find= these sorts of simplifications of structure, we should take advantage of= them. >> >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. > >Sure, 1837 is a *very* long term goal (frankly I'm not convinced >that we get even 1830 out of the door, but that does not depress me. >It's a hobby!). > I think that if we can set realistic milestones for ourselves, we'll get it= done. Right now, I'd just like to see a working stockmarket. Once that works, we= can look at getting a working game map put together. After that, we'll aim= for a working auction for private companies. And so on, and so on, until= we've got a fully working game. We will get there. The important thing is to not let the large scope of the= project take away from being able to achieve each of the smaller goals= that, when combined, will allow us to achieve the larger project goals.= :-) ---Brett. |
|
From: Erik V. <eri...@hc...> - 2005-03-05 10:41:59
|
> >The StockChart moveXxxx() methods already write the moves to > System.out, > >if that is what you want. > >(I guess this will later be replaced by writing to a log). > > > > The reason I suggest using toString() is that this will allow > us to use it for many other things beyond simply testing the classes. > > For example, it's an easy way for us to gather reporting data > about the state of the game by using each objects toString() > method rather than polling every getFoo() method for every > property within the object. Well, you can always call toString(), but perhaps you mean to customise its output? Like what? I was talking about objects reporting their state *changes*. We need that to create a readable game log (e.g. for PBEM). Using toString() to report *current state* is fine with me. Erik. |
|
From: John D. G. <jd...@di...> - 2005-03-05 13:32:49
|
Erik Vos wrote:
> I was talking about objects reporting their state *changes*.
> We need that to create a readable game log (e.g. for PBEM).
I like this in principle. However, since money does not appear or
disappear but goes somewhere, I suggest that all money movements be
handled by a single function ("Transfer" with two arguments) and
logged as a single action. If "add $30 to Player 1" and "subtract
$30 from the Bank" are two separate actions, it's too easy for one
to get done and the other skipped.
|
|
From: Erik V. <eri...@hc...> - 2005-03-05 14:38:55
|
I absolutely agree.
StockChart now has a generic log method,
which is called by all move methods, and reads:
logMove(String companyName, StockPrice from, StockPrice to) {
if (to == null || from == to) {
System.out.println (companyName+" stays at
"+from.getName());
} else {
System.out.println (companyName+" moved from
"+from.getName()+" to "+to.getName());
}
}
where System.out will later be changed to a log file handle.
Erik.
> -----Original Message-----
> From: rai...@li...
> [mailto:rai...@li...] On Behalf Of
> John David Galt
> Sent: 05 March 2005 14:33
> To: rai...@li...
> Subject: Re: [Rails-devel] Stock market revisited
>
> Erik Vos wrote:
> > I was talking about objects reporting their state *changes*.
> > We need that to create a readable game log (e.g. for PBEM).
>
> I like this in principle. However, since money does not appear or
> disappear but goes somewhere, I suggest that all money movements be
> handled by a single function ("Transfer" with two arguments) and
> logged as a single action. If "add $30 to Player 1" and "subtract
> $30 from the Bank" are two separate actions, it's too easy for one
> to get done and the other skipped.
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from
> real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
|
|
From: Brett L. <wak...@ea...> - 2005-03-05 19:01:07
|
>> For example, it's an easy way for us to gather reporting data >> about the state of the game by using each objects toString() >> method rather than polling every getFoo() method for every >> property within the object. > >Well, you can always call toString(), but perhaps you mean >to customise its output? Like what? > >I was talking about objects reporting their state *changes*. >We need that to create a readable game log (e.g. for PBEM). > >Using toString() to report *current state* is fine with me. > Yes, I meant customizing the toString() output. I highly doubt the default= toString() output will be very helpful. ;-) You're right that we were talking about different things. Perhaps if we use toString() to output the current object state as XML,= that gives us an easy method of generating both game logs and a game state file for things like PBEM. ---Brett. |
|
From: Erik V. <eri...@hc...> - 2005-03-05 22:09:53
|
> >Well, you can always call toString(), but perhaps you mean
> >to customise its output? Like what?
> ><snip>
> Yes, I meant customizing the toString() output. I highly
> doubt the default toString() output will be
> very helpful. ;-)
><snip>
> Perhaps if we use toString() to output the current object
> state as XML, that gives us an easy method of generating
> both game logs and a game state file for things like PBEM.
OK.
I presume that in the case of the stockmarket we only need to
save the token locations, as all other info is available in
the initialisation XML (item <stockmarket>).
So would the following toString() output be OK for StockChart/StockMarket?
<stockmarket_state>
<square_state name="G7">
<market_token company="B&O"/>
<market_token company="NYC"/>
</square_state>
...
</stockmarket_state>
As shown, we should translate funny characters ('&' becomes '&').
If this the only character to watch it's no problem,
but to solve the general case we would need some existing package.
Erik.
|
|
From: Erik V. <eri...@hc...> - 2005-03-05 10:55:13
|
> As was mentioned before, linear is just rectangular with a
> single row. No special class needed there.
By the way, the 1860 linear stock market is divided in two rows ("tiers"),
the second being shifted half a space with respect to the first.
PayOut/Withhold goes left and right by "1 space" == "2 places".
Selling shares goes back "1 place" per share (unless in the green area),
which is up-left or down-left (zig-zag).
Here we definitely need the Model/View separation!
Basically this market is linear, but the total number of spaces (columns) is
53!
So the Model will be linear, but the View cannot be so for space reasons.
Erik.
|
|
From: Stewart T. <wsr...@ho...> - 2005-03-04 18:13:12
|
Erik, >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(). Please think very carefully that you understand the implications of making the constructor "private" in Java when creating a singleton class. A class with a private constructor is implicitly final and cannot be extended with a subclass. As long as you want to prohibit subclasses of your singleton, then this is fine. However, if there is a possibility that it might be useful at some point for someone to create a subclass, then it is better to make the constructor "protected". Please note, I'm not suggeesting that StockMarket should not be a singleton, I'm simply making an observation about Java style and behaviour. You're going to be busy this weekend... have fun... I'm off skiing, so I'll b ehaving fun too! cheers Stewart |
|
From: Erik V. <eri...@hc...> - 2005-03-04 20:14:01
|
Yes, it should of course be protected. Lame excuse: it's 8 months ago I did my last Java before I started here, it seems the fine points get rusty soon.... Thanks, Erik. > -----Original Message----- > From: rai...@li... > [mailto:rai...@li...] On Behalf Of > Stewart Thain > Sent: 04 March 2005 19:12 > To: rai...@li... > Subject: RE: [Rails-devel] Stock market revisited > > Erik, > > >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(). > > Please think very carefully that you understand the > implications of making > the constructor "private" in Java when creating a singleton > class. A class > with a private constructor is implicitly final and cannot be > extended with a > subclass. As long as you want to prohibit subclasses of your > singleton, then > this is fine. However, if there is a possibility that it > might be useful at > some point for someone to create a subclass, then it is > better to make the > constructor "protected". > > Please note, I'm not suggeesting that StockMarket should not > be a singleton, > I'm simply making an observation about Java style and behaviour. > > You're going to be busy this weekend... have fun... I'm off > skiing, so I'll > b ehaving fun too! > > cheers > > Stewart > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X