Vis a tergo

Baseball cards as objects - from players to leaders

So, say you wanted to hold your baseball card collection in a database. What would the object model look like? It's one of those problems that sounds simple originally, but gets more complex as you add some of the intricacies and outside cases that have been introduced into baseball cards through the years, either by mistake or by design.

If your collection consisted only of cards between 1952 and 1980, it would make the problem quite a bit easier. I'll make it even easier and pick one year to start -- 1968. I've already thought through a lot of this, but there are some interesting problems right off the bat [npi].

So, think of a standard baseball card. On the front, it has a picture of the player, his name, his position and his team. On the back, there's a card number, and it repeats his name, position and team, along with some personal information (height, weight, which side he bats/throws from, his birthdate, and where he lives). It also contains yearly statistics for his career. Sometimes it has a short biographical blurb, and ends with a piece of trivia in the form of a cartoon at the bottom of the card. Here's Frank Robinson's card as an example:

Now, we don't need all of this information to keep track of all of the cards we own. Once we can identify a unique card, we can just go to the collection itself to see the interesting tidbits contained on it. Later on, we can add as much detail as we like. It seems like the minimal amount of information we need is the card number itself. We probably want to add some more identifying information to make any reports we generate more interesting, but the card number seems to be a unique identifier all by itself. So, let's take a first cut at our "BaseballCard" object. I'll use Java, just because it's the language I'm most fluent in.

public class BaseballCard {

  private int number;
  private String playerName;
  private String teamName;

  public int getNumber() {
    return number;
  }

  public void setNumber(int num) {
    number = num;
  }

  public String getPlayerName() {
    return playerName;
  }

  public void setPlayerName(String name) {
    playerName = name;
  }

  public String getTeamName() {
    return teamName;
  }

  public void setTeamName(String name) {
    teamName = name;
  }

}

Let's take a look at a list of the cards from 1968 and see if our assertion about the card number fails. There are a lot of sources for card set lists, and I'm just going to use the one here for now. Starting at the beginning, a number of problems become obvious within the first ten cards. First, using just the number on the back of the card won't work. You can see that card #10 has a variation, and there isn't actually a card #10. There are two variations, "10a" and "10b". Apparently, Topps misspelled Boston Red Sox pitcher Jim Lonborg's name incorrectly then corrected it in later printings. Many collectors will collect both versions of the card, so we need to make allowances for variations. Another problem shows up right at card #1. There are three players on the card, and it's identified as a card that shows the National League Batting Leaders. It has pictures of Roberto Clemente, Tony Gonzalez and Matty Alou, who all play for different teams. It also has text at the top that says "1967 Batting Leaders", and a blue circle that identifies it as "National League".

The back of the card has the card number, and a list of the top 50 batting leaders for the 1967 season with their name and batting average. So let's try and modify our object model to include the problems we've just identified.

There are a couple of ways that we could modify the class to accommodate variations. We could change the type of the number field to a String, and just accept alphabetic characters. I'm going to start off by leaving that field alone, though. I'm going to add a field that identifies whether the card is a variation, then add another field for the description of the variation. I may change my mind later, but I want to see how this works.

public class BaseballCard {

  private int number;
  private boolean variation;
  private String variationDescription;
  private String playerName;
  private String teamName;

  public int getNumber() {
    return number;
  }

  public void setNumber(int num) {
    number = num;
  }

  public String getPlayerName() {
    return playerName;
  }

  public void setPlayerName(String name) {
    playerName = name;
  }

  public String getTeamName() {
    return teamName;
  }

  public void setTeamName(String name) {
    teamName = name;
  }

  public void setVariation(boolean b) {
    variation = b;
  }

  public boolean isVariation() {
    return variation;
  }

  public void setVariationDescription(String desc) {
    variationDescription = desc;
  }

  public String getVariationDescription() {
    return variationDescription;
  }
}

That takes care of allowing variations, but what about allowing more than one player to be attached to the card? It looks like we're going to have to create a Player class and keep a list of them attached to the card. It can hold any information we want to keep about the player and be re-used for different cards. Let's just create a very simple class to start off with.

public class Player {
  private String name;
  private String team;
  
  public String getName() {
    return name;
  }
  public void setName(String n) {
    name = n;
  }
  public String getTeam() {
    return team;
  }
  public void setTeam(String t) {
    team = t;
  }
}

Now we just need to modify our BaseballCard class to hold an ArrayList of players instead of one player's name and team name. We'll also add a method to get the list of players, and a method that will allow us to add players to the list.

import java.util.ArrayList;

public class BaseballCard {

  private int number;
  private boolean variation;
  private String variationDescription;
  private ArrayList<Player> players;

  public BaseballCard() {
    players = new ArrayList<Player>();
  }

  public int getNumber() {
    return number;
  }

  public void setNumber(int num) {
    number = num;
  }

  public void setVariation(boolean b) {
    variation = b;
  }

  public boolean isVariation() {
    return variation;
  }

  public void setVariationDescription(String desc) {
    variationDescription = desc;
  }

  public String getVariationDescription() {
    return variationDescription;
  }

  public ArrayList<Player> getPlayers() {
    return players;
  }
  
  public void addPlayer(Player player) {
    players.add(player);
  }

}

Finally, since we've found that cards can be about different subjects than just a single player, I'm going to add a generic description field for now. Later a better way to identify these insert cards might come to me.

import java.util.ArrayList;

public class BaseballCard {

  private int number;
  private String description;
  private boolean variation;
  private String variationDescription;
  private ArrayList<Player> players;

  public BaseballCard() {
    players = new ArrayList<Player>();
  }

  public int getNumber() {
    return number;
  }

  public void setNumber(int num) {
    number = num;
  }

  public void setDescription(String desc) {
    description = desc;
  }

  public String getDescription() {
    return description;
  }

  public void setVariation(boolean b) {
    variation = b;
  }

  public boolean isVariation() {
    return variation;
  }

  public void setVariationDescription(String desc) {
    variationDescription = desc;
  }

  public String getVariationDescription() {
    return variationDescription;
  }

  public ArrayList<Player> getPlayers() {
    return players;
  }
  
  public void addPlayer(Player player) {
    players.add(player);
  }

}

Now we should be able to create a set of cards where each of the cards can be attached to multiple players. Any of the cards can have a variation associated with it, and we can describe the variation in detail.

Next time we'll go further down the checklist and see how well our current object model supports the different card types.

Closed comments because of comment spam Posted by Rob at January 15, 2008 04:17 PM