From: <wak...@ea...> - 2005-04-26 18:46:42
|
>I'm from a school of thought that classes should be self-managing, >which is why I tend to include static arrays and methods to manage >the instances of a class inside that class, as I have done in Player. I agree with you that for some things, this is the right way to go. This is especially true for classes that only ever really need one instance, such as Bank. Though, now that I think about it, perhaps Bank should be a totally static class? >About the Player[] allPlayers (I tend to use ArrayLists >because these do not need to be pre-dimensioned): sure, >but my point is: where do we store such an array? >I have put it as a static array inside Player (the class, not the instance) >itself. We would store such an array in the initialization code for starting up a new game. I've already been working a bit on this sort of initialization: see ui/GameLoader.java >But, as I already have indicated in an earlier post, self-managing classes >turn out not to fit well with the style of component management and XML >parsing that we have started to use, so that a PlayerManager class >already needs to be considered. >So I probably (though somewhat reluctantly) have to agree with you.... >Long live the proliferation of classes! :-( Ok... I've gotten further along in coding the startup UI for a new game. Included with that, I'll pull out the self-managing portions of Player so that it can be used for storing a single player's data. I'll be committing this sometime later today. Things are starting to look a lot like an actual game. It's quite encouraging. I've also found a good profiler plugin for Eclipse: http://eclipsecolorer.sourceforge.net/index_profiler.html This has let me track down the reason for the StockChart's horrible performance. In short, it's because the paintComponent method for each token is being called over and over and over to the point where nothing else is able to be repainted. I'm working on a solution for that as well. ---Brett. |