Classes that reference each other
In my app, I need to track where people are sitting.
The way I stupidly did it at first was as follows:
"Person" has a "Table" and "Seat" attribute.
"Table" has multiple "Seats".
"Seat" has a "Person" attribute.
All seating is done through a class that handles the connections.
What is the best way to do this?
What's nice about the way it is now is that it is really easy to get information on where someone sits...just ask the player. Or, if you want to know who is in a seat, just ask the seat.
Removing the "Table" and "Seat" attributes from "Person" seems to make sense, but that adds a lot of overhead to the lookups.
Any advice?
[697 byte] By [
jneaua] at [2007-10-2 13:30:29]
Is the overhead causing a performance problem? If not I would just go with a Table that has Seats where each Seat has a Person in it. I'm not even sure "Seat" is necessary, why can't a Table simply keep track of how many Persons are at it and where? Even if Seat is necessary you could map each Person to a Seat and the lookup would be very quick by asking the Table which Seat a Person is in.
> In my app, I need to track where people are sitting.
>
> The way I stupidly did it at first was as follows:
>
> "Person" has a "Table" and "Seat" attribute.
> "Table" has multiple "Seats".
> "Seat" has a "Person" attribute.
I'm not sure that I'd agree with a Seat class. What behavior does a Seat have? It's more like an index or key into the underlying data structure that lets you extract the Person value associated with it. (Hint: Think Map of <Seat, Person> pairs where Seat can be a String or number.)
>
> All seating is done through a class that handles the
> connections.
>
> What is the best way to do this?
>
> What's nice about the way it is now is that it is
> really easy to get information on where someone
> sits...just ask the player. Or, if you want to know
> who is in a seat, just ask the seat.
>
> Removing the "Table" and "Seat" attributes from
> "Person" seems to make sense, but that adds a lot of
> overhead to the lookups.
>
> Any advice?
Since a Seat and Person combination makes no sense without a Table, I'd have Table seat folks and keep track of where they are.
As far as convenience goes, there's no reason you can't have several methods in Table that would hide all that complexity of seating arrangements. I'd have a method that would have Table tell me a Seat given a Person object, or a Person given a Seat object.
Writing a Web-based Texas Hold 'Em app? 8)
%
Written. Just improving it.
drneau.com
Thanks.
The reasoning I had behind the Seat class was so that I could listen to the seat for changes rather than listening to the table.
Seat has also developed a property over time for "locked" to lock a player in a seat so that they aren't automatically reseated.
jneaua at 2007-7-13 11:14:39 >
Okay. Here's what I've come up with.
The existing classes are:
- Player (okay, the cat's out of the bag...it's a player...)
- Floor - has 0 to n "Tables". Simply an ordered collection of tables that also has the ability to answer questions like "how many open seats are there?"
- Table - has 0 to n "Seats". Primary attribute is "name".
- Seat
What if I added a new class called "SeatingChart" which had 0 to n "SeatingChartEntry"s?
There would be one "SeatingChartEntry" for each player. SeatingChartEntry would have an optional relationship to a Table and a Seat.
That means that a "SeatingChart" would have to:
- Listen to the player Roster to know when a new player was added or removed.
- Listen to the floor to know when a new Table was added or removed
- Listen to each Table to know when a seat is added or removed, and possibly veto seat removal requests if the seat is occupied.
Thoughts?
jneaua at 2007-7-13 11:14:39 >
Have fun m8. Nothing wrong with what you are doing. Bi-directional relationships are just for what you used it for. To speed up and simplify a reverse lookup.
Your thinking is correct. Thats the important part.
Seating chart is fine if it serves a specific purpose. Don't add it just to create a prettier heirachy. You can always refactor later.
