Example Model - Basketball Teams and Players

Last Updated: May 5, 1996

Object model

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, name, which is read-only and which serves as the functional key for the object. The only time a user of this class can set the name is on object creation. The other attributes (wins, losses, and players) can be modified throughout the lifetime of this object.
We enforce the encapsulation of the attributes by making the attributes have non-public visibility. Instead, we provide accessors ("setters") and mutators ("getters") that have the same name as the attribute. Also, in all the mutators, we notify anyone who might care (the Observers) that the attribute has changed. The argument that we send along with the notification is the name of the attribute that changed.
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: firstName, lastName, and birthdate. Again, you can only set these attributes when you are creating the object. The last attribute, shootingPercentage, can be changed throughout the lifetime of the object.
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.

Go back to the tutorial introduction.

Object model
	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, `name`, which is read-only and which serves as the functional key for the object. The only time a user of this class can set the name is on object creation. The other attributes (`wins`, `losses`, and `players`) can be modified throughout the lifetime of this object. We enforce the encapsulation of the attributes by making the attributes have non-`public` visibility. Instead, we provide accessors ("setters") and mutators ("getters") that have the same name as the attribute. Also, in all the mutators, we notify anyone who might care (the Observers) that the attribute has changed. The argument that we send along with the notification is the name of the attribute that changed.	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: `firstName`, `lastName`, and `birthdate`. Again, you can only set these attributes when you are creating the object. The last attribute, `shootingPercentage`, can be changed throughout the lifetime of the object. 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.