Smart and Dumb Constructors in C#

When I am coding in C#, I often run into a design decision about how smart or dumb to make a class constructor. Even after quite a few years of dealing with the issue, it’s still not clear to me what the best approach is. By a smart constructor, I mean one which has some code logic. By a dumb constructor I mean one which has no, or very little, code logic.

The problem is best described with a specific example. Recently I was working with college basketball data in an effort to ultimately predict the results of the NCAA March Madness championship tournament. One of literally thousands of ways to store game information in memory resembles this:

class GameData
  public string date;
  public int dateNumber;

  public string homeName;
  public int homeID;
  public int homeScore;

  // etc. for visitor team

The date is the date on which a game as played, like “02/09/2014”. The dateNumber is a 0-based integer where 0 is the first day of the basketball season, 1 is the second day, and so on. Field homeName is something like “Utah St”. Each of the roughly 1560 college teams needs a program-defined ID like 784.

A dumb constructor would look like this:

public GameData(string date, int dateNumber,
  string homeTeam, etc.)
{ = date;
  this.dateNumber = dateNumber;
  // etc.

The idea is that the class is really just a simple container (essentially a struct data type). This means that the work of computing derived fields dateNumber and homeID would have to be done externally to the constructor call using auxiliary functions, along the lines of:

string date = "02/09/2014";
int dateNumber = DateNumber(date);
// . .
string homeTeam = "Utah St";
int teamID = TeamID(homeTeam, listTeams);
// . .
GameData gd = new GameData(date, dateNumber, . .);

On the other hand, a smart constructor would use class-member helper methods, for example:

public GameData(string date, string homeTeam,
{ = date;
  this.dateNumber = DateNumber(date);
  // etc.

Both approaches will work fine, and I’ve used both approaches many times. But I’ve never really been able to come up with a set of guidelines for deciding which approach is better — either most of the time as a general rule, or under a particular set of circumstances.

No moral to this post; just an illustration that there’s more to programming than just getting code to work.

This entry was posted in Machine Learning. Bookmark the permalink.