|
|
Object-Oriented Programming Concepts: A Primer |
In the real world, you often have many objects of the same kind. For example, your bicycle is really 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. All 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 other bicycles.When building bicycles, manufacturers take advantage of the fact that bicycles share characteristics and they build many bicycles from the same blueprint--it would be very inefficient to produce a new blueprint for every individual bicycle they 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 the 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. Software "blueprints" for objects are called classes.
Definition: A class is a blueprint or prototype that defines the variables and the methods common to all objects of a certain kind.
For example, you could create the bicycle class that would declare several variables to contain the current gear, the current cadence, etc. It would also declare and provide implementations for the methods that allow the rider to change gears, brake and change the pedaling cadence.
The values for the variables are provided by each instance of the class. So, after you've created the bicycle class, you must instantiate it (create an instance of it) before you can use it. When you create an instance of a class, the variables declared by the class are allocated in memory. Then you can use the instance's methods to assign values to the variables. Instances of the same class share method implementations.
The Term "Object"
You probably noticed that the illustrations of objects and classes look very similar to one another. And indeed, the differentiation 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 that they describe--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 also because many people use the term "object" inconsistently and use it to refer to both classes and instances.In the diagrams, a class's methods and variables are not shaded because they don't exist yet. You must create an instance from the class before you can call the methods and before the variables can have any values. In comparison, an object's methods and variables are shaded indicating that the object actually exists and you can use it. You can send the object a message and it will respond by performing the method and perhaps modifying the values of the variables.
The Benefit of Classes
Objects provide the benefit of modularity and information hiding. Classes provide the benefit of reusability. Bicycle manufacturers reuse the same blueprint over and over again to build lots of bicycles. Software programmers use the same class over and over again to create many objects.
|
|
Object-Oriented Programming Concepts: A Primer |
