The Perl You Need to Know Part 24: Introduction to Object Oriented Perl - Page 169
May 21, 2001
|
As in watercolors, programming is a matter of perspective —
there are several ways to view the same scene, and anyone else's
way is clearly wrong. That's where object oriented programming,
or OOP, comes in, an increasingly popular "other way" to approach
working with data in programs. While important languages such as
C++ and Java are founded on OOP principles, Perl is typically
accomodating, supporting either traditional or OOP perspectives.
Although use of object orientation in Perl is technically
optional, in practice you are likely to at least rub shoulders
with the object model when using external modules. In fact, we've
already seen object syntax in this series when working with the
ever popular CGI and DBI modules. This month, we'll take stock of
that syntax, and begin a broader understanding of what working
with objects in Perl is really all about.
|
Objects of Our Affection
While working with object oriented programming is portrayed as
somehow novel, leading edge, or requiring deep study, we actually
use object orientation in our lives daily. Every appliance in
your kitchen, for instance, flaunts the principles of OOP.
Consider the stove: it probably has four knobs, one for each
burner. The stove's interface requires that you turn a knob to
make a burner more or less hot. You are not directly concerned
with how the stove makes the burner hot (maybe it uses a
spark and gas fuel, maybe it uses an electric element, and so on)
— the interface merely requires you to turn the knob.
Extend the same analogy to your microwave oven and the same
principles apply, although the interface is more complex and
supports operations more highly abstracted than directly
controlling degree of heat. In other words, the microwave, like
the stove, still ultimately heats food via a process of no
concern to you, but the microwave determines heat level
indirectly by way of higher order parameters — power
level, time, or even type of food (potato, popcorn, etc.).
The typical metaphor for a program object is the "black box", a
hypothetical device that you control with buttons or levers, and
it does its thing internally. The crucial aspect of the black box
(stove, microwave, etc.) and therefore of an object in OOP is
that its external interface is decoupled from its internal
function. This has two important consequences:
- Anyone can leverage the power of the object simply by
learning its interface, without needing to understand how the
object achieves its goals. The power of this model can be seen
all around us, from vacuum cleaners to stoves to the cars we
drive, and even the computers we use.
- Designers and engineers can modify, incrementally or
radically, the internal function of the object while minimzing
change to its external interface. If you can drive to the market
in a Dodge Neon you could probably also do so in a Porsche Boxter
or an electric hybrid Honda Insight, because they share
fundamentally similar interfaces, while functioning quite
differently internally.
Therein lies the programmer's affection for objects, especially
as building blocks. Indeed, we'll soon see just how closely
objects in Perl are related to the traditional Perl building
blocks of modules and packages.
Contents:
Classism
A Matter of (Indirect) Syntax
A Private Stash (of modules) - Page 168
The Perl You Need to Know
Classism - Page 170
|
