Objects in Operation

This page attempts to give you a mental model for thinking about an object oriented program in operation.

It is useful to think of an executing object oriented program as a graph or web of objects (nodes) and communication paths (arcs). An object communicates with another by sending it a message. This message is a request for service. The sender is the client and the receiver is the server. The receiver will fulfill the service request and perhaps return information to the sender. Often the server must rely on other objects to help it fulfill the service request. It then itself acts as a client to these other objects which act as servers for it. Control returns to the message sender even if no information is returned.

In the figure on this page each oval represents an object. The arrows represent communication paths. If an object is shown in black it is executing currently. If bullets move along an arrow in the direction of an arrow, the executing object is communicating with another object, which will then become the active object. When that object completes the request, control returns to the original object as indicated by bullets moving along the arrows in the direction opposite the way the arrow is pointing. Eventually the control returns to the object that started the chain of communication.

It is also possible for an object to communicate with itself, when it is executing one method and needs to execute another while the first suspends.

Only one object is in operation at a time. (In a multi-threaded program this need not be true actually.)

To communicate with another object we send it a message consisting of one of its method names with appropriate parameters. The sending object suspends while the receiver executes the method. Eventually control returns to the sender. When any method is finished control returns to the object that send this message.

Not all objects will participate in any given chain of communication. Which ones do depends on data in the program and the specific needs of the individual objects in fulfilling requests.

Usually the communication paths are represented in a Java program by having the object at the tail of the arrow have an instance variable which refers to the object at the head of the arrow. The object holding the reference can then send a message to the object to which the reference variable "points." A message looks like

	objectName.methodName(parameter...);

However, a message from an object to itself looks like

	methodName(parameter...);

If there is an arrow from A to B then A is a client and B is a server.

Note that this animation will repeat a few times and then stop. To see it again, reload this page.

Here is a simple example with only two objects. These will be from different classes. We call the classes Client and Server to emphasize the roles played here.

Our Server is a "Count server" It keeps a count of the number of times it has been accessed and returns that count when asked.

class Server
{	public int count(){ return value++;} //Handle a request for service
	private int value = 0;
}

A client for this server needs to somehow be able to find the server. We will make a server a parameter of its constructor.

class Client
{	public Client(Server s){aServer = s;}

	public void makeRequest()
	{	savedValue = aServer.count();  //The message (service request)
	}

	private Server aServer;
	private int savedValue = -1;
}

We can use these classes as follows.

Server server = new Server();
Client client = new Client(server);

client.makeRequest();

When the client makes the request it sends the count message to its server reference. The client waits while the server fulfills the request. The server object then carries out the request by returning its current value (and incrementing that value internally). The server then halts operation. The client then gets the result and resumes its operation by saving the returned value in the savedValue variable.

April 15, 2000