Objects and Classes

We call the various entities that interact during the execution of a program objects, and organize these into classes based upon their commonalities. More formally, objects of the same class share a common encoding of their underlying data representation and support a common set of operations. For example, in the previous discussion,DigitalPhotomay be the name of a class. A single object from a given class is termed an instance of that class, for examplemeAtTheArchandhoneymoonInEurope. Internally, each instance is repre-sented by one or more pieces of data which we call attributes (although we occasionally use synonyms such as data members, fields, or instance variables). The fact that objects are drawn from the same class means that they are represented using the same group of attributes, yet the values of those attributes may or may not be the same. For example, each photo has a width and height, but the dimensions of each photo are not necessarily the same. Taken together, the attribute values of a particular instance comprise what we term the state information, representing the precise condition of the object at a given time.

Notice that over time some attributes of an object (and thus the overall state) may change.

The operations supported by instances of a class are known as methods (although we occasionally use synonyms such as actions, behaviors, or member functions). The methods supported by an object provide the mechanism for interacting with that object.

Collectively, the attributes and methods of an instance are called its members.

Example: the obedient dog

In general, we think of an object as a passive thing that does not do anything unless explic-itly told to do so. As an analogy, we compare it to the stereotypical well-trained dog. If we were to define a classDog, we might take time to consider what attributes and meth-ods should be included. Perhaps we would include attributes such asbirthdate,hairColor, eyeColor,weight,location,posture, andtemperament, and methods such assit,lieDown, rollOver, andfetch. If an instance of theDogclass, namedspot, is created, it would pas-sively await commands from others. To interact withspot, an entity calls one of its sup-ported methods (this is synonymously termed invoking a method). The entity that invokes the method is termed the caller and will often be some other object in the larger system;

spot : Dog

lieDown( )

rollOver( ) jane : Person

sit( )

FIGURE 1.3: A sequence diagram demonstrating interactions between jane, an instance of a presumed Person class, and spot, an instance of Dog.

the entity upon which the method is invoked is termed the callee. The typical syntax used for such a method call in an object-oriented programming language isspot.sit( ). Behind the scene, a message reaches the callee when one of its methods has been called, and in this casespotwould perform whatever behavior is associated with the methodsit. If a sequence of method calls are made, they are performed one at a time in the order in which they are invoked.

Figure 1.3 contains a graphical representation of a simple sequence of interactions.

We call such a figure a sequence diagram. At the top is a label for each object, identifying a unique name (e.g.,jane) as well the class from which it is drawn (e.g.,Person). The vertical line drawn down from the label represents the chronological lifespan of that object. Each solid arrow represents the invocation of a method, oriented from caller to callee (e.g.,jane invoking thesitmethod upon spot). When a method is called, we say that the flow of control is passed from the caller to the callee. At that time, the caller waits until the callee completes the action. In our diagram, a white rectangle on the callee’s side denotes the duration of time when that action is being performed. At its conclusion, the flow of control is passed back to the caller, as diagrammed with a dashed line in our figure. So in this example, afterspotfinishes sitting, we see thatjaneinvokes thelieDownmethod, waits for that to complete, and then finally calls therollOvermethod.

Each method has its own semantics based upon an underlying algorithm. Instances of the same class rely upon an identical implementation that is specified as part of the class definition. Yet that is not to say that each invocation of a given method causes the identical behavior. The instructions may take into account the current state of an object.

For example, the precise mechanics of how a dog with short legs sits may be different from that of a dog with long legs. Even a single object can exhibit different behaviors for a method at different times, depending on the current state. If we callspot.sit( )at a time whenspotis in a lying posture, the execution of that command would presumably be

spot : Dog

redSlippers jane : Person

fetch(slippers)

FIGURE 1.4: Sequence diagram in which jane invokes spot.fetch(slippers)

different than if called whenspotis in a standing posture. However, it is worth noting that the behavior of the callee does not depend overtly upon the identity of the caller. In this way, our analogy of an object as a well-trained dog is fallacious; a well-trained dog might behave differently when its master tells it to sit as opposed to a stranger.

The methods serve as the primary avenue of communication with an object. Even in its simplest form, as inspot.sit( ), there is an aspect of communication captured purely in the decision to invoke this method (as opposed to callingspot.lieDown( )or calling no method whatsoever). Yet in some cases, additional information must be passed from the caller to the callee. We call such a piece of information a parameter. Consider thefetch method of classDog. There could be several possible things that one might ask a dog to fetch. A parameter can be used to designate this information, as inspot.fetch(slippers)as opposed tospot.fetch(newspaper). Of course, there must be an a priori agreement for each method as to how many parameters are expected, what types of information are to be sent, and in what order. We note that in the case ofspot.sit( ), we intentionally use parentheses to clearly denote this as an invocation of a method with zero parameters.

Often, we wish to have a way for the callee to communicate information back to the caller after performing some action. For example, at the conclusion ofspot.fetch(slippers), spotmay have an object to return to the caller (ideally, the slippers). This kind of informa-tion passing is supported by allowing a callee to send a return value back to the caller at the conclusion of a method call. Figure 1.4 shows a sequence diagram for the call tofetch, with both the parameter and return value displayed. As with parameters, there should be a clear agreement as to what information will be returned, if any. The overall agreement regarding the expected parameters and return value for a method is called its signature, and is documented as part of the class definition.

Methods serve various purposes. Some do not cause any change in the object’s current state, but rather are used by the caller to request information about that state. Such methods are commonly termed accessors or inspectors and necessitate the use of a return value. For example, ourDogclass might support the syntaxgetPosture( )to let a caller know whether a dog is currently sitting, standing or lying. Other methods, such assit( ), may affect the state of the callee; such a method is termed a mutator. Althoughsit( )does does not use any parameter or return value, other mutators may. Finally we note that some methods are neither accessors or mutators. For example if we presume that a dog returns precisely to the original position after fetching an object, thefetchmethod has no lasting effect on the state of the dog nor does it inform the caller about that state. Instead, it is used to initiate a broad action, in this case one that affects a third object, the slippers.