|
|
||||||||||||||
|
|
|
|
|
|||||||||||
|
|
||||||||||||||
|
|
Home
|
 |
|
Object-Oriented Terminology
In this section, we review some of the phrases and terms that get used
in discussing object-oriented programming. These phrases have specific
meanings, but are often used carelessly. We will try to clearly define
these terms, as they will be used frequently in the following sections
of this article. (Non-Newbies can safely skip this section, and proceed
to Object
Relationship Notation.)
Object-Oriented ProgrammingBefore we can discuss the notion and notation of acquisition in Part II, we first need to talk a bit about object-oriented programming (OOP). Object-oriented languages, such as Java, Python, and C++ have become imensely popular in the last five years. But a computer chip doesn't know whether it is running object-oriented code or not. The ones and zeros that provide instructions to the computer look no different whether the programming language being used is object-oriented or not. So the main benefit of using an object-oriented language is to help us, the computer programmers, rather than the computer.Most anything can be modeled in some fashion using almost any programming language. Using basic data types (such as integer, floating point number, string) and commands of any popular programming language, we could model a motorcycle, for instance. Our code could store information about the motorcycle's weight, color, power, and speed. We could have a function called start() that modeled turning on the ignition. There could be a function called go() that modeled how far the motorcycle moved during a given time period. Virtually anything that the motorcycle might do we can model without using any object-oriented techniques. But let's say that once we were done modeling the motorcycle, we wanted to model a car. Now we could copy the code we had generated for the motorcycle and modify it to work for a car. Obviously, a few things would be different for a car than for a motorcycle. The car has four wheels instead of two. And the car could take more passengers than a motorcycle. But the start() and go() functions would be almost the same for a car as it was for a motorcycle. This is where object-oriented programming becomes handy. Instead
of rewriting code for the car, we could use objects to segment and
simplify our programming efforts. So we might want to first create a bit
of code called "vehicle." This "vehicle" code could be programmed to handle
functions such as start() and go() that are common to
all vehicles. Other bits of code, such as "car," "truck," "bulldozer,"
and "motorcycle" could therefore be written so as to share the "vehicle"
code. This cuts down on the amount of code we have to write. It also ensures
that if we get the code written correctly in one place, all the other uses
of that code will work properly. If a programming language supports this
inheritance of code between objects, it is termed an object-oriented
language.
Object InheritanceSince "vehicle" is specifying what bits of code similar software models should inherit, it is known as a class. And we can create other classes, such as "car" and "motorcycle" that inherit properties from the "vehicle" class. Our "car" and "motorcycle" classes are thus subclasses of the "vehicle" class. We can create subclasses of the "car" or "motorcycle" class, such as "passenger_car", "race_car", "motocross", and "minibike". Each of these subclasses shares the general characteristics of their parent class, but also has characteristics unique to their own class.
The characteristics associated with each class are known as attributes. An attribute can be either a property or a method. A property is a parameter that describes a class characteristic, such as weight, color, or number of tires. (Other terms for properties are data members, class variables, and fields.) A method is a segment of code that models a function or activity of the class, such as start() or go(). Methods typically perform calculations that utilize its class properties. When we finished creating specifications for groups of objects with similar characteristics (i.e. classes), we could create an object representing a particular object. This is known as an instance. So using the class "passenger_car", we could construct an instance of "my_chevy_cavalier" that represents the old clunker sitting out in your driveway. (Car models and performance may vary, so check your local listings.) If you tried to execute the function start() on your instance
"my_chevy_cavalier", the notation might look something like:
my_chevy_cavalier.start()And the program would look for a for a segment of code in the "my_chevy_cavalier" object that told it how to start the car. And if it couldn't find it, the search would transfer to the "passenger_car" class for such information. If the start() function were not found there, then the "car" class would be scanned for a start() function. And finally, if not found in one of the subclasses, the "vehicle" object would be asked to supply a start() function. Now that we've defined a few object related terms, let look at how relationships between objects are typically notated in Object Relationship Notation.
|
Search zopeNewbies: Search zopeNewbies 2: |
|||||||||
|
|
Last update: Friday, November 26, 1999 at 8:59:58 AM Pacific. |
|||||||||||||
