In many existing game classes, game parameters and lists are now
implemented as static (class) variables, and/or are accessible
through static getters.
There are several reasons why I think we should move away from
class attributes and methods for game-dependent data:
1. Class attributes make starting a game irreversible
(or would require extra reinitialisation code for a restart).
Inother words, the game startup code is not re-entrant.
Personally, I don't consider this much of a problem, as one
can always quit and restart if game initialisation fails because of
bad XML or whatever else. But opinions may vary on this matter,
and, generally spoken, reentrant code is better anyway.
2. Class attributes and methods stand in the way of extending the
functionality of a class by subclassing. This is not yet an big issue,
but I expect that it soon will be when we are going to implement more games.
In particular, I would not be surprised if subclassing GameManager
becomes a necessity for the "special rounds" that exist in some games:
Prussian formation in 1835, Ferdinandea Secession and Tuscanian
merge in 1841, Minor Company Final Exchange Round in 18EU, etc.
3. In the (far) future, we might want to build a server to facilitate
multiple simultaneous Internet games. In such a server, nothing
that is game-dependent can be static. (I know this is a long shot,
but we can better move towards than away from this goal).
For the above reasons, I have turned all game-dependent static attributes
in Game and GameManager into instance attributes.
These classes are still singletons, and most getters are still static,
but it's a first step.
Erik Vos
|
