| << Chapter < Page | Chapter >> Page > |
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 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.
Classes are the fundamtental 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.
SuppSuppose 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.
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 was created in the
module on Abstraction , 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?
To download a zipped file containing the code above, click one of the following links:
Both of the above codebases include a DrJava project file (.pjt) that can be opened from DrJava to easily manage all the code and test files.
Notification Switch
Would you like to follow the 'Principles of object-oriented programming' conversation and receive update notifications?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|