Comp201: Principles of Object-Oriented Programming I
Spring 2006 -- Lec04: Abstraction using Objects and Classes   

The little dragon shown in class can be found at the web site of the Grand Illusions Toy Shop in England: 

Summary: An introduction to the concepts of objects and classes

Objects

In the "real" world, objects are the entities of which the world is comprised. Everything that happens in the world is related to the interactions between the objects in the world. Just as atoms, which are objects, combine to form molecules and larger objects, the interacting entities in the world can be thought of as interactions between and among both singular ("atomic") as well as compound ("composed") objects. The real world consists of many, many objects interacting in many ways. While each object may not be overly complex, their myriad of interactions creates the overall complexity of the natural world. It is this complexity that we wish to capture in our software systems.

In an object-oriented software system, objects are entities used to represent or model a particular piece of the system.

Objects are the primary units used create abstract models.

There are a number of schools of object-oriented programming, which differ slightly on how they view objects. Here, we will take a "behaviorist" (our term) stance:

An object is characterized solely by it behaviors.

Essentially this defines an object by the way it interacts with its world. An object that does not interact with anything else effectively does not exist. Access to internally stored data is necessarily through some sort of defined behavior of the object. It is impossible for an outside entity to truly "know" whether or not a particular piece of data is being stored inside of another object.

This does not mean however, that an object may not contain data (information) in fields. The essence of the object is in how the object behaves in relationship to or as a result of its data, should it contain any. The existence of data in an object is an implementation technique used to generate the required behavior of that object.  Objects are not "bags of data".

Classes

Many objects differ from each other only in the value of the data that they hold. For example, both a red crayon and a blue crayon are crayons; they differ only in the value of the color attribute, one has a red color and the other a blue color. Our object-oriented system needs a way to capture the abstraction of a crayon, independent of the value of its name. That is, we want to express that a set of objects are abstractly equivalent, differing only in the values of their attributes and perhaps, thus differing in the behaviors that result from those values.

Many objects are similar in many overall, generalized ways, differing only in smaller, more specific details. In biology and other fields, scientists organize objects into taxonomies, which are classification hierarchies used to express these similarities. For instance, a butterfly and a lobster are quite different, yet they share the common characteristics of all Arthropods, such as a jointed exoskeleton. The notion of an Arthropod enables us to understand and deal with butterflies and lobsters in an abstract, unified manner. So once again we are trying to express abstract equivalence.

Object-oriented systems use classes to express the above notions of abstract equivalence.

A class is an abstract description of a set of objects.

A class thus contain the descriptions of all the behaviors of the objects that it represents. In computer science parlance, we call the individual behaviors of a class its methods. In addition, a class may, but not always, contain descriptions of the internal data held by the objects, called its fields, as well as implementation details about its methods and fields.

Turning the description around, we can say that a class is a template or recipe for the creation of a particular type of object. That is, one can use a class to create ("instantiate") objects of the type described by the class. Be careful not to make the very beginner's common mistake of equating classes and objects. A class is a specification of an set of objects, it is not the actual object.

In technical terms, a class defines a new type (See Lec02) in the system. Types are identifies used to differentiate different kinds of data. For instance, integers, characters, strings and arrays are all types of data.

Implementation in Java

Classes are the fundamental building blocks of Java programs. Defining a class is basically a matter of specifying a name for the class, its relationship to other classes and what sort of behaviors the class exhibits as well as what data it may contain.
Suppose we wanted to define a class to describe a household pet. We could do it as such: 
	class Pet {
	}
The word class above is called a keyword and can only be used to state that the following code is the definition of a class. The class keyword is immediately followed by the desired name of the class, Pet here. The curly braces, {...}, indicate the extent of the definition of the class. That is, any definitions of the class's behaviors and data will be found between the curly braces. Curly braces must therefore always appear as a matched set.

In general, in Java, curly braces mark the extent of a definition.

Style note: The accepted typographic standard in the Java community is that the opening curly brace is at the end of a line and the ending curly brace is at the beginning of its own line. Any code between the curly braces is indented.

Well, our class for pets is simple, but not very interesting because it doesn't do anything.    We could say that our pet has a name, but personally, I have found that the behavior of most pets is not affected by the particular name we give them.   That is, we can give our pet a name but that doesn't change the way they behave.     Let's try something else.

Pets eat a certain amount of food per day.   Pets have a certain weight.   Let's create a model, that states that the number of hours that a pet sleeps per day is related to the amount of food they eat and their weight.  Thus we could say that a pet has a behavior of sleeping a certain number of hours depending on its weight and the amount of food eaten.

/**
 * A class that models a household pet
 */
class Pet{
  
  /**
   * The weight of the pet in lbs
   */
  double weight;  
  
  /**
   * The number of hours the pet will sleep after eating
   * the given lbs of food.
   * @param lbsOfFood The number of lbs of food eaten.
   * @return The number of hours slept after eating the food.
   */
  double hoursSlept(double lbsOfFood) {
    return 24.0*lbsOfFood/weight;
  }
}
But what about the pet's owner (a person, supposedly)? A person is not such a simple thing as a weight. Assigning a number to every possible person in the world is possible but not necessarily the most practical technique.   There are many ways to represent people:  the Registrar likes to think of you as a number with credit hours and unpaid bills, The CS department sees you as a 8-character login and unfinished graduation requirements, your doctor sees you as a collection of pulsating blood vessels, cells and bones, and your parents see you as this sweet little thing just out of diapers.   A person is still a person, but the way that we choose to represent them may differ from situation to situation.  

But here's the crux of the issue:  does your pet care how you are internally represented?   Or does your pet just want something that is a person to be their owner?

/**
 * A class that models a household pet
 */
class Pet{
  
  /**
   * The weight of the pet in lbs
   */
  double weight;  
  
  /**
   * The pet's owner
   */
  Person owner;
  
  /**
   * The number of hours the pet will sleep after eating
   * the given lbs of food.
   * @param lbsOfFood The number of lbs of food eaten.
   * @return The number of hours slept after eating the food.
   */
  double hoursSlept(double lbsOfFood) {
    return 24.0*lbsOfFood/weight;
  }
  
  /**
   * Determines whether or not this pet is happy to see a 
   * particular person. 
   * @param p The person who the pet sees.
   * @return true if the Person is their owner, false otherwise.
   */
  boolean isHappyToSee(Person p) {
    return p == owner;
  }
}
Here we've added a field of type Person, which is a class used to represent people. It doesn't matter how Person is implemented, just that it is a representation of a person.    We could use the class definition of Person that we created in class the other day, or perhaps one that is fixed up a little bit, or perhaps a completely new one.   The Pet doesn't care.

Thus we see that objects can contain objects.  What does this say about the possible complexity of a system of objects?

Download today's code:

Last Revised Thursday, 03-Jun-2010 09:50:14 CDT

©2006 Stephen Wong and Dung Nguyen