Re: StatsTable object
markspace wrote:
bob wrote:
What do you all think of this representation? I think it would be
better if it had a more 2-dimensional feel, but I don't want to
complicate things.
I don't like it. I think it would be better to represent the rows as
classes, and then compose the object as a collection of those objects.
I know this sounds like a bit of extra work, but in the long run it's
probably better.
+1
For example, if you wanted to use a JTable, which is a table for GUI
display, having the actual types as ints, double, etc. instead of
strings would be a big advantage because the default display/editing
will use those types and "do the right thing" in many cases.
Something like:
public class PlayerStats {
String name;
int touchdowns;
double yardsRushing;
double yardsPassing;
... getters/setters...
public int getPropertyCount() { return 4; }
public int getPropertyNames() {
return new String[] { "Name","Touchdows","Yards Rushing",
"Yards Passing", };
}
public class StatsTable {
ArrayList<PlayerStats> playerStats;
... don't need "rows" use playerStats.getSize()
... columns: use getPropertyCount()...
}
Plus, 'vector' is not a type in the standard API. If it's a custom type, i=
t needs to follow the naming conventions. If you meant 'java.util.Vector',=
don't use that type.
There is almost no excuse really to use 'java.util.Vector' in new code. It=
was (largely) supplanted by 'ArrayList' (and the 'Collections.synchronized=
List()' or 'synchronizedCollection()' versions thereof) about thirteen YEAR=
S ago.
(The exception is in order to deal with legacy code that contains vestigial=
'Vector' references, but that is not the case for the OP.)
Others have mentioned that there might be use cases for using a table-orien=
ted representation, but that seems on the face of it inappropriate for this=
exercise. I suggest sticking with the object-oriented approach initially =
unless you can explain why the table oriented approach is better.
Also, I notice the OP's first "row" lacked a label for the player name.
--
Lew