There is almost always some set of objects which reflect the business domain of the problem you are trying to solve. The objects constitute the model of the application. The definitions of these objects are distinct from the manner in which a user can interact and view these objects. The domain for a number of examples is that of basketball teams and players.
Each business object is represented by a class that has both attributes and behavior. We have subclassed each object under the Observable class, which allows other objects to be notified when the business object changes state. The individual classes are described below.
The Team object
The first object we have defined is the Team object. You can look at the source code, but you'll find out that it is a very simple object. It has one attribute, |
We enforce the encapsulation of the attributes by making the attributes have non-
|The Smalltalk code for the Team object is found in Team.st.|
The Player Object
The Player object (with source code) follows the same conventions as the Team object, except there are three read-only attributes: |
One special note about the Date class. It seems that it can't represent a date that occurred before 1970. This sucks. Since this is just an example, I've just made all the players 10 years younger than they actually are, but this obviously won't work for real business applications.
|The Smalltalk code for the Player object is found in Player.st.|