8.2. Using Set Methods During Object Creation

Consider the way the model swarm level of a simulation can be designed. If the values of many variables are set inside the ModelSwarm.m file, and those values are to be passed to the individual agents at the time of creation, then the code that creates individual objects might be designed like this:

aBug = [Bug createBegin: globalZone];
aBug = [aBug createEnd];
[aBug setWorldSizeX: xsize Y: ysize];
[aBug setFoodSpace: foodSpace];
[aBug setX: xPos Y: yPos];
[aBug setIdealTemp: [uniformDblRand getDoubleSample]];

This code presupposes that the ModelSwarm.m file has pre-existing variables (probably integers) xsize, size, xPos, and yPos, as well as an object foodSpace and an object uniformDblRand that can give back a random number. This code also presupposes that set methods exist for the Bug class that can get these jobs done.

There are some matters of "taste" and "judgment" that affect model design. One might ask, for example: "why does this code set the ideal temperature in this way?" Why not create a method inside the Bug.m file, such as initializeValues like so:

- initializeValues
{
  idealTemperature= [uniformDblRand getDoubleSample] 
  return self;
}

If this method existed, then the code that creates the bug and sets values in it could have the command

 [aBug setIdealTemp: [uniformDblRand getDoubleSample]];

replaced with this:

 [aBug initializeValues];

This would achieve the purpose of setting the idealTemperature variable inside the object called aBug. And, from the information-hiding perspective of object-oriented programming, it seems better because the value drawn for the variable idealTemperature is never exposed to any other object.

There are a few practical reasons why the first way of setting the ideal temperature might be preferred. First, for the programmer's convenience, it is nice to have as many of the "parametric" changes in a single file as possible. The Bug class can be written and never edited again if all of the changes needed are kept in the ModelSwarm.m file. Second, you might save memory dealing with these things in the ModelSwarm.m file. Suppose that the object uniformDblRand has to be created in order to draw a random number. If you insist on writing a method like initializeValues inside the Bug.m, then you need to worry about how that random number generator object is created inside each bug object. It certainly saves memory to create just one random generator in the ModelSwarm.m file and then draw numbers from it inside the model swarm itself. There are some good arguments for this approach in the literature on random number generation. The issue seems somewhat esoteric, but the argument is that one is better off making repeated draws from the same random number generator than making one call against each of the many random number generators. For reasons like this, Swarm examples tend to have information translated into objects from the model swarm level, even though it is technically allowable to have that information-creation process completely isolated within the object.