Start of Tutorial > Start of Trail > Start of Lesson |
Search
Feedback Form |
In the real world, you often have many objects of the same kind. For example, your bicycle is just one of many bicycles in the world. Using object-oriented terminology, we say that your bicycle object is an instance of the class of objects known as bicycles. Bicycles have some state (current gear, current cadence, two wheels) and behavior (change gears, brake) in common. However, each bicycle's state is independent of and can be different from that of other bicycles.When building them, manufacturers take advantage of the fact that bicycles share characteristics, building many bicycles from the same blueprint. It would be very inefficient to produce a new blueprint for every bicycle manufactured.
In object-oriented software, it's also possible to have many objects of the same kind that share characteristics: rectangles, employee records, video clips, and so on. Like bicycle manufacturers, you can take advantage of the fact that objects of the same kind are similar and you can create a blueprint for those objects. A software blueprint for objects is called a class (see the following figure).
A visual representation of a class.
The class for our bicycle example would declare the instance variables necessary to contain the current gear, the current cadence, and so on for each bicycle object. The class would also declare and provide implementations for the instance methods that allow the rider to change gears, brake, and change the pedaling cadence, as shown in the next figure.
Definition: A class is a blueprint that defines the variables and the methods common to all objects of a certain kind.After you've created the bicycle class, you can create any number of bicycle objects from that class. When you create an instance of a class, the system allocates enough memory for the object and all its instance variables. Each instance gets its own copy of all the instance variables defined in the class, as the next figure shows. The bicycle class.
MyBike
andYourBike
are two different instances of theBike
class. Each instance has its own copy of the instance variables defined in theBike
class but has different values for these variables.In addition to instance variables, classes can define class variables. A class variable contains information that is shared by all instances of the class. For example, suppose that all bicycles had the same number of gears. In this case, defining an instance variable to hold the number of gears is inefficient; each instance would have its own copy of the variable, but the value would be the same for every instance. In such situations, you can define a class variable that contains the number of gears (see the following figure); all instances share this variable. If one object changes the variable, it changes for all other objects of that type.
YourBike
, an instance ofBike
, has access to thenumberOfGears
variable in theBike
class; however, theYourBike
instance does not have a copy of this class variable.A class can also declare class methods. You can invoke a class method directly from the class, whereas you must invoke instance methods on a particular instance.
The Understanding Instance and Class Members section discusses instance variables and methods and class variables and methods in detail.
Objects provide the benefit of modularity and information-hiding. Classes provide the benefit of reusability. Bicycle manufacturers use the same blueprint over and over again to build lots of bicycles. Software programmers use the same class, and thus the same code, over and over again to create many objects.
You've probably noticed that the illustrations of objects and classes look very similar. And indeed, the difference between classes and objects is often the source of some confusion. In the real world, it's obvious that classes are not themselves the objects they describe; that is, a blueprint of a bicycle is not a bicycle. However, it's a little more difficult to differentiate classes and objects in software. This is partially because software objects are merely electronic models of real-world objects or abstract concepts in the first place. But it's also because the term object is sometimes used to refer to both classes and instances.In illustrations such as the top part of the preceding figure, the class is not shaded because it represents a blueprint of an object rather than the object itself. In comparison, an object is shaded, indicating that the object exists and that you can use it.
Start of Tutorial > Start of Trail > Start of Lesson |
Search
Feedback Form |
Copyright 1995-2005 Sun Microsystems, Inc. All rights reserved.