Chapter 9. Object-Oriented Programming

What is object-oriented programming? A good many books have been devoted to that topic in full, and many more, like this one, in part.

Although it isn't difficult to give a fairly short description of what object-oriented programming is , I believe that one learns object-oriented programming mostly by experience and necessity. This is a long, difficult, and interesting process, enough so that I will not have room in this section to bring you up to speed from scratch. This section is intended mostly for readers who are already familiar with another object-oriented language like C++ or Smalltalk. However, even if you are a complete novice, if you work your way through the examples here and experiment a little along the way, you should begin to get a feel for things.

The essence of object-oriented programming is that an object-oriented program is structured around typed data. Object-oriented programming languages have features that allow you to create objects (data structures) of one or more classes (types) and then have the type of the objects automatically determine which functions are called in a program's execution. Such functions are called methods .

In the good old days you might have written code like:

 $a{'type'} = 'LogMsg';  $a{'data'} = 'some text';  # ... some intervening stuff ...  if ($a{'type'} eq 'LogMsg') {    write_to_log($a{'data'});  } elsif ($a{'type'} eq 'ConsoleMsg') {    write_to_console($a{'data'});  } 

This is not object-oriented, because it contains explicit type-checking logic and so-called " type fields" that are the mortal enemy of good object-ori-ented style. The primary distinguishing feature of object-oriented programming languages is that they allow programmers to eliminate code like the above, leaving to the programming language the responsibility of selecting functions based on type. In Perl 5 you could write the above as:

 package LogMsg;  sub new { my ($pkg, $data) = @_; bless { data => $data } };  sub Write { my $self = shift; print LOG "$self->{data}\n" };  package ConsoleMsg;  sub new { my ($pkg, $data) = @_; bless { data => $data } };  sub Write { my $self = shift; print "$self->data\n" };  package main;  $a = new LogMsg('some text');  $a->Write(); 

Here we have defined LogMsg and ConsoleMsg classes, then created an object, $a , of class LogMsg . Perl automatically invokes the subroutine LogMsg::Write when we call the Write method for an object of class LogMsg .

The advantages of this style of programming are immediately obvious to anyone who ever has written or maintained a program that contains long passages of code resembling the first example. The improvement is mostly structural. If you want to add another kind of object (say, a FlashingLightMsg ), all you have to do is add the code that defines the object and its behavior. With the non- object-oriented style of programming, you have to go picking through your source code looking for all the places where you test the type of your data, then change the code appropriately.

The disadvantages are also obviousthe code is longer and uses conventions that are confusing to the uninitiated. These are nontrivial issues. Object-oriented programming is not the most appropriate solution for every problem.

The term "object-oriented" has grown to encompass a number of features beyond simple objects, classes, and methods. For example, you will hear discussions of constructors, destructors, inheritance, multiple inheritance, polymorphism, overloading, and of course a number of C++-isms like templates and inlining. If you haven't experienced object-oriented programming before, it can be bewildering, expecially if you get the full treatment right off the bat. As you strive to learn what it is and how it is practiced, keep objects, classes, and methods foremost in your mind they are its essence.