Object-Oriented Programming Concepts

You've heard it a lot in the past several years. Everybody is saying it.

What is all the fuss about objects and object-oriented technology? Is it real? Or is it hyped? Well, the truth is – it's a little bit of both. Object-oriented technology does, in fact, provide many benefits to software developers and their products. However, historically a lot of hype has surrounded this technology causing confusion in both managers and programmers alike. Many companies fell victim to this hardship (or took advantage of it) and claimed that their software products were object-oriented when, in fact, they weren't. These false claims confused consumers, causing widespread misinformation and mistrust of object-oriented technology.

However, in spite of overuse and misuse of the term object-oriented, the computer industry is now beginning to overcome the hype. Understanding is growing about this technology and its benefits.

This lesson slashes through the hype and explains the key concepts behind object-oriented programming, design, and development.

1.1 What Is an Object?

An object is a software bundle of variables and related methods. Software objects are often used to model real-world objects you find in everyday life.

1.2 What Are Messages?

Software objects interact and communicate with each other using messages.

1.3 What Are Classes?

A class is a blueprint or prototype that defines the variables and the methods common to all objects of a certain kind.

1.4 What Is Inheritance?

(Or what does my grandmother's money have to do with all of this?)

A class inherits state and behavior from its superclass. Inheritance provides a powerful and natural mechanism for organizing and structuring software programs.

1.5 Where Can I Get More Information?

This lesson gives you a glimpse into the world of object-oriented design and development and may whet your appetite for more. Check out other fine publications in this subject of object-oriented titles to get more information about this exciting technology!

This lesson provides a basis for understanding key object-oriented terminology and concepts. Understanding these new terms and concepts is just the beginning. As you begin to design and program in languages like C++ & Java, a truely object-oriented language, the power of objects and classes will become apparent.

1.1 What Is an Object?

As the name object-oriented implies, objects are key to understanding object-oriented technology. You can look around you now and see many examples of real-world objects: your dog, your desk, your television set, your bicycle.

These real-world objects share two characteristics: they all have state and they all have behavior. For example, dogs have state (name, color, breed, hungry) and dogs have behavior (barking, fetching, and slobbering on your newly cleaned slacks). Bicycles have state (current gear, current pedal cadence, two wheels, number of gears) and behavior (braking, accelerating, slowing down, changing gears).

Software objects are modeled after real-world objects in that they, too, have state and behavior. A software object maintains its state in variables and implements its behavior with methods.

Definition: An object is a software bundle of variables and related methods.

You can represent real-world objects using software objects. You might want to represent real-world dogs as software objects in an animation program or a real-world bicycle as a software object within an electronic exercise bike. However, you can also use software objects to model abstract concepts. For example, an Event is a common object used in GUI window systems to represent the action of a user pressing a mouse button or a key on the keyboard.

The following illustration is a common visual representation of a software object:

Everything that the software object knows (state) and can do (behavior) is expressed by the variables and methods within that object. A software object that modelled your real-world bicycle would have variables that indicated the bicycle's current state: its speed is 10 mph, its pedal cadence is 90 rpm, and its current gear is the 5th gear. These variables and methods are formally known as instance variables and instance methods to distinguish them from class variables and class methods (which are described later in What Are Classes?).

The software bicycle would also have methods to brake, change the pedal cadence, and change gears. (The bike would not have a method for changing the speed of the bicycle, as the bike's speed is really just a side-effect of what gear it's in, how fast the rider is pedaling, whether the brakes are on, and h ow steep the hill is.)

Anything that an object does not know or cannot do is excluded from the object. For example, your bicycle (probably) doesn't have a name, and it can't run, bark, or fetch. Thus there are no variables or methods for those states and behaviors in the bicycle class.

As you can see from the diagrams, the object's variables make up the center or nucleus of the object. Methods surround and hide the object's nucleus from other objects in the program. Packaging an object's variables within the protective custody of its methods is called encapsulation. Typically, encapsulation is used to hide unimportant implementation de

tails from other objects. When you want to change gears on your bicycle, you don't need to know how the gear mechanism works, you just need to know which lever to move. Similarly in software programs, you don't need to know how a class is implemented, you just need to know which methods to invoke. Thus, the implementation details can change at any time without effecting other parts of the program.

This conceptual picture of an object--a nucleus of variables packaged within a protective membrane of methods--is an ideal representation of an object and is the ideal that designers of object-oriented systems strive for. However, it's not the whole story. Often, for implementation or efficiency reasons, an object may wish to expose some of its variables or hide some of its methods.

In many languages, including Java, an object can choose to expose its variables to other objects allowing those other objects to inspect and even modify the variables. Also, an object can choose to hide methods from other objects forbidding those objects from invoking the methods. An object has complete control over whether other objects can access its variables and methods and in fact, can specify which other objects have access.

< The Benefits of Encapsulation

Encapsulating related variables and methods into a neat software bundle is a simple yet powerful idea that provides two primary benefits to software developers:

Ø Modularity--the source code for an object can be written and maintained independently of the source code for other objects. Also, an object can be easily passed around in the system. You can give your bicycle to someone else and it will still work.

Ø Information hiding--an object has a public interface that other objects can use to communicate with it. But the object can maintain private information and methods that can be changed at any time without affecting the other objects that depend on it. You don't need to understand the gear mechanism on your bike in order to use it.

1.2 What Are Messages?

A single object alone is generally not very useful and usually appears as a component of a larger program or application that contains many other objects. Through the interaction of these objects, programmers achieve higher order functionality and more complex behavior. Your bicycle hanging from a hook in the garage is just a bunch of titanium alloy and rubber; by itself the bicycle is incapable of any activity. The bicycle is useful only when when another object (you) interacts with it (starts pedaling).

Software objects interact and communicate with each other by sending messages to each other. When object A wants object B to perform one of B's methods, object A sends a message to object B.

Sometimes the receiving object needs more information so that it knows exactly what to do--for example, when you want to change gears on your bicycle, you have to indicate which gear you want. This information is passed along with the

message as parameters.

Three components comprise a message:

1. The object to whom the message is addressed (Your Bicycle)

2. The name of the method to perform (changeGears)

3. Any parameters needed by the method (lower gear)

These three components are enough information for the receiving object to perform the desired method. No other information or context is required.

< The Benefits of Messages

Ø An object's behavior is expressed through its methods, so (aside from direct variable access) message passing supports all possible interactions between objects.

Ø Objects don't need to be in the same process or even on the same machine to send and receive messages back and forth to each other.

1.3 What Are Classes?

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 other bicycles.

When building bicycles, manufacturers take advantage of the fact that bicycles share characteristics by building 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 methods common to all objects of a certain kind.

For example, you could create a bicycle class that declares several instance variables 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.

The values for instance 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, you create an object of that type and the system allocates memory for the instance variables declared by the class. Then you can invoke the object's instance methods to make it do something. Instances of the same class share the same instance method implementations (method implementations are not duplicated on a per object basis), which reside in the class itself.

In addition to instance variables and methods, classes can also define class variables and class methods. You can access class variables and methods from an instance of the class or directly from a class--you don't have to instantiate a class to use its class variables and methods. Class methods can only operate on class variables--they do not have access to instance variables or instance methods.

The system creates a single copy of all class variables for a class the first time it encounters the class in a program--all instances of that class share its class variables. For example, suppose that all bicycles had the same number of gears. In this case defining an instance variable for 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 situations such as this, you could define a class variable that contains the number of gears. All instances share this variable. If one object changes the variable, it changes for all other objects of that type.

Objects vs. Classes

You probably noticed that the illustrations of objects and classes look very similar to one another. 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 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 it's also because many people use the term "object" inconsistently and use it to refer to both classes and instances.

In the diagrams, the class is not shaded because it represents a blueprint of an object rather than an object itself. In comparison, an object is shaded indicating that the object actually exists and you can use it.

< 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, and thus the same code, over and over again to create many objects.

1.4 What Is Inheritance?

Generally speaking, objects are defined in terms of classes. You know a lot about an object by knowing its class. Even if you don't know what a penny-farthing is, if I told you it was a bicycle, you would know that it had two wheels, handle bars, and pedals.

Object-oriented systems take this a step further and allow classes to be defined in terms of other classes. For example, mountain bikes, racing bikes, and tandems are all different kinds of bicycles. In object-oriented terminology, mountain bikes, racing bikes, and tandems are all subclasses of the bicycle class. Similarly, the bicycle class is the superclass of mountain bikes, racing bikes, and tandems.

Each subclass inherits state (in the form of variable declarations) from the superclass. Mountain bikes, racing bikes, and tandems share some states: cadence, speed, and the like. Also, each subclass inherits methods from the superclass. Mountain bikes, racing bikes, and tandems share some behaviors: braking and changing pedaling speed, for example.

However, subclasses are not limited to the state and behaviors provided to them by their superclass. What would be the point in that? Subclasses can add variables and methods to the ones they inherit from the superclass. Tandem bicycles have two seats and two sets of handle bars; some mountain bikes have an extra set of gears with a lower gear ratio.

Subclasses can also override inherited methods and provide specialized implementations for those methods. For example, if you had a mountain bike with an extra set of gears, you would override the "change gears" method so that the rider could actually use those new gears. You are not limited to just one layer of inheritance. The inheritance tree, or class hierarchy, can be as deep as needed. Methods and variables are inherited down through the levels. In general, the further down in the hierarchy a class appears, the more specialized its behavior.

< The Benefits of Inheritance

Ø Subclasses provide specialized behaviors from the basis of common elements provided by the superclass. Through the use of inheritance, programmers can reuse the code in the superclass many times.

Ø Programmers can implement superclasses called abstract classes that define "generic" behaviors. The abstract superclass defines and may partially implement the behavior but much of the class is undefined and unimplemented. Other programmers fill in the details with specialized subclasses.