Best structure to use...class getting too big
Need a little advise.
I write a poker tournament management application. In the app, I have a "Player" class to track info on a player including their name, email, phone, etc. A also use that class to track information that changes dynamically throughout a tournament, such as:
- money paid in
- money paid out
- current state
- etc.
I want to separate the more static fields from the fields that are dynamic during a tournament...and part of the reason is I want the "Player" class to be more portable outside of the context of a tournament.
So, some options:
Option 1: Break the dynamic info into a new class and have the Player class reference it. That's better, but still don't think it is the ultimate.
Option 2: Create a "Tournament Player" class that encapsulates "Player" (basically, a delegation). That seems better, but I don't want to have to provide a getting and setter in "Tournament Player" for each method in "Player" that I might need to access...or do I just provide a "getPlayer" method in "Tournament Player".
[1093 byte] By [
jneaua] at [2007-10-2 13:30:28]
> Need a little advise.
>
> I write a poker tournament management application.
> In the app, I have a "Player" class to track info on
> n a player including their name, email, phone, etc.
Classic - sounds like a Party pattern. I'd call this class Person or Party instead of Player to emphasize that it can be used outside of a game context.
> A also use that class to track information that
> t changes dynamically throughout a tournament, such
> as:
> - money paid in
> - money paid out
> - current state
> - etc.
>
> I want to separate the more static fields from the
> fields that are dynamic during a tournament...and
> part of the reason is I want the "Player" class to be
> more portable outside of the context of a
> tournament.
Excellent thinking.
> So, some options:
>
> Option 1: Break the dynamic info into a new class and
> have the Player class reference it. That's better,
> but still don't think it is the ultimate.
Not as reusable.
> Option 2: Create a "Tournament Player" class that
> encapsulates "Player" (basically, a delegation).
> That seems better, but I don't want to have to
> o provide a getting and setter in "Tournament Player"
> for each method in "Player" that I might need to
> access...or do I just provide a "getPlayer" method in
> "Tournament Player".
Actually, I don't think that you need to wrap or subclass Person. Let that dynamic class that will keep track of all the status and money stuff have a reference to Person (e.g., private Person player). This design lets you keep the static Person info with its dynamic game state stuff and still reuse Person elsewhere.
Excellent thinking, great question. If only there were more like this.
%
> > That seems better, but I don't want to have to
> > o provide a getting and setter in "Tournament
> Player"
> > for each method in "Player" that I might need to
> > access...or do I just provide a "getPlayer" method
> in
> > "Tournament Player".
I would return the instance rather than providing forwarding methods.
lets not seperate 'static fields.' Lets seperate out the behaviors that make sense. For instance, you can create a moneyManager class. now instead of managing money paid in and paid out, you just use the money manager and call methods on it.
So the player instance can encapsulate or aggregrate an instance of the MoneyManager class.
Note, even static stuff related to money should not be in money manager class.
I am having a little doubt here as to whether Player rises to the level of a class. From what I have heard maybe it should just be an instance of HashMap. Then TournamentPlayer can have a reference to that HashMap.Drake
> duffymo:
> Actually, I don't think that you need to wrap or
> subclass Person. Let that dynamic class that will
> keep track of all the status and money stuff have a
> reference to Person (e.g., private Person player).
> This design lets you keep the static Person info
> o with its dynamic game state stuff and still reuse
> Person elsewhere.
How is that not wrapping the Person?
> kablair:
> I would return the instance rather than providing
> forwarding methods.
I agree but there should be a Player interface that is separate from Person that is subclassed for different contexts.
> Drake_Dun:
> I am having a little doubt here as to whether Player
> rises to the level of a class. From what I have
> heard maybe it should just be an instance of HashMap.
> Then TournamentPlayer can have a reference to that
> HashMap.
If the properties are not dynamic, then this seems to offer no advantage.
> If the properties are not dynamic, then this seems to> offer no advantage.Well, it is not like writing a separate class won't work. But if all that class is is a hard-wired map, isn't it more straightforward to just use an actual Map?Drake
> > If the properties are not dynamic, then this seems
> to
> > offer no advantage.
>
> Well, it is not like writing a separate class won't
> work. But if all that class is is a hard-wired map,
> isn't it more straightforward to just use an actual
> Map?
Superficially yes. But you'll need to know the keys to do anything programmatically with these values so you need to define constants somewhere and then if you later want to add behavior (like validation) to the class you end up either having to refactor or with disparate logic spread through your code or a helper class (which is basically OO without the Os.)
> Well, it is not like writing a separate class won't
> work. But if all that class is is a hard-wired map,
> isn't it more straightforward to just use an actual
> Map?
I just want to point out that I am not against this approach in general but for data that is a fundamental part of the application, I find this to be less maintainable. There are some hybrid approaches that I have also played around with.
> Need a little advise.
>
> I write a poker tournament management application.
> In the app, I have a "Player" class to track info on
> n a player including their name, email, phone, etc.
> A also use that class to track information that
> t changes dynamically throughout a tournament, such
> as:
> - money paid in
> - money paid out
> - current state
> - etc.
>
All of the above is data.
There is no behavior.
Is there any behavior that you intend to separate out as well?
