Object design of a list of things

[fishfry]

Suppose I have a simple (flat) data structure, say for example a hash
with keys name, position, average representing baseball players.

In my program I might often need a list of these hashes, along with
methods that look up an object based on name, etc.

I have a class called PlayerList, which holds a list of players, along
with various methods for looking up, adding, and deleting players from
the list.

What are the pros and cons, in OO design terms, of having a separate
class for the data structure, say Player.pm, versus not having a
separate class?

For example in the former case I would add a new player to the list by
saying

my $playerList = new PlayerList(name=>'name', position=>'outfield',
average=>.300);
my $player = new Player();
$playerList->add($player);

versus

my $playerList = new PlayerList();
$playerList->add({name=>'name', position=>'outfield', average=>.300};

 

[Anno Siegel]

Suppose I have a simple (flat) data structure, say for example a hash
with keys name, position, average representing baseball players.

In my program I might often need a list of these hashes, along with
methods that look up an object based on name, etc.

I have a class called PlayerList, which holds a list of players, along
with various methods for looking up, adding, and deleting players from
the list.

What are the pros and cons, in OO design terms, of having a separate
class for the data structure, say Player.pm, versus not having a
separate class?

Use separate classes. This doesn't only go for OO. Whenever you
have the choice of keeping two problems apart or merging them into
one, keep them apart.

Write a general list class that makes as few assumptions about its
elements as possible. Write a player class that doesn't assume
the players are going to be collected in lists. Then put the two
together.

For example in the former case I would add a new player to the list by
saying

my $playerList = new PlayerList(name=>'name', position=>'outfield',
average=>.300);
my $player = new Player();
$playerList->add($player);

This doesn't make much sense. You are creating a PlayerList with
parameters that pertain to a single player. Are you assuming PlayerList
stores these values for the creation of new players? That doesn't look
like a good arrangement.

versus

my $playerList = new PlayerList();
$playerList->add({name=>'name', position=>'outfield', average=>.300};

That still assumes that PlayerList knows how to create players, coupling
the classes closer than necessary. Here is my take (untested):

my $playerlist = List->new;
$playerList->add(
Player->new( name=>'name', position=>'outfield', average=>.300),
);

# ...

my @good = $playerList->search( sub { $_->average >= .300 });

############################################################
package Player;

sub new {
my $class = shift;
bless { @_}, $class;
}
sub name { $_[ 0]->{ name} }
sub average { $_[ 0]->{ average} }
# etc.

############################################################
package List;

sub new { bless [], shift }

sub add {
my $list = shift;
push @$l, @_;
}

sub search {
my $list = shift;
my $code = shift;
grep $code->(), @$list;
}
__END__

Note that the classes Player and List are completely independent. In
a practical implementation you may not be able to keep them as cleanly
apart as in this model, but that's the direction to go.

Anno