Chapter 12. Objects

First of all, you need to understand packages and modules; see Chapter 10, "Packages", and Chapter 11, "Modules". You also need to know about references and data structures; see Chapter 8, "References" and Chapter 9, "Data Structures". It's also helpful to understand a little about object-oriented programming (OOP), so in the next section we'll give you a little course on OOL (object-oriented lingo).

12.1. Brief Refresher on Object-Oriented Lingo

An object is a data structure with a collection of behaviors. We generally speak of the behaviors as acted out by the object directly, sometimes to the point of anthropomorphizing the object. For example, we might say that a rectangle "knows" how to display itself on the screen, or that it "knows" how to compute its own area.

Every object gets its behaviors by virtue of being an instance of a class. The class defines methods: behaviors that apply to the class and its instances. When the distinction matters, we refer to methods that apply only to a particular object as instance methods and those that apply to the entire class as class methods. But this is only a convention--to Perl, a method is just a method, distinguished only by the type of its first argument.

You can think of an instance method as some action performed by a particular object, such as printing itself out, copying itself, or altering one or more of its properties ("set this sword's name to Anduril"). Class methods might perform operations on many objects collectively ("display all swords") or provide other operations that aren't dependent on any particular object ("from now on, whenever a new sword is forged, register its owner in this database"). Methods that generate instances (objects) of a class are called constructor methods ("create a sword with a gem-studded hilt and a secret inscription"). These are usually class methods ("make me a new sword") but can also be instance methods ("make a copy just like this sword here").

A class may inherit methods from parent classes, also known as base classes or superclasses. If it does, it's known as a derived class or a subclass. (Confusing the issue further, some literature uses "base class" to mean a "most super" superclass. That's not what we mean by it.) Inheritance makes a new class that behaves just like an existing one but also allows for altered or added behaviors not found in its parents. When you invoke a method whose definition is not found in the class, Perl automatically consults the parent classes for a definition. For example, a sword class might inherit its attack method from a generic blade class. Parents can themselves have parents, and Perl will search those classes as well when it needs to. The blade class might in turn inherit its attack method from an even more generic weapon class.

When the attack method is invoked on an object, the resulting behavior may depend on whether that object is a sword or an arrow. Perhaps there wouldn't be any difference at all, which would be the case if both swords and arrows inherited their attacking behavior from the generic weapon class. But if there were a difference in behaviors, the method dispatch mechanism would always select the attack method suitable for the object in question. The useful property of always selecting the most appropriate behavior for a particular type of object is known as polymorphism. It's an important form of not caring.

You have to care about the innards of your objects when you're implementing a class, but when you use a class, you should be thinking of its objects as black boxes. You can't see what's inside, you shouldn't need to know how it works, and you interact with the box only on its terms: via the methods provided by the class. Even if you know what those methods do to the object, you should resist the urge to fiddle around yourself. It's like the remote control for your television set: even if you know what's going on inside it, you shouldn't monkey with its innards without good reason.

Perl lets you peer inside the object from outside the class when you need to. But doing so breaks its encapsulation, the principle that all access to an object should be through methods alone. Encapsulation decouples the published interface (how an object should be used) from the implementation (how it actually works). Perl does not have an explicit interface facility apart from this unwritten contract between designer and user. Both parties are expected to exercise common sense and common decency: the user by relying only upon the documented interface, the designer by not breaking that interface.

Perl doesn't force a particular style of programming on you, and it doesn't have the obsession with privacy that some other object-oriented languages do. Perl does have an obsession with freedom, however, and one of the freedoms you have as a Perl programmer is the right to select as much or as little privacy as you like. In fact, Perl can have stronger privacy in its classes and objects than C++. That is, Perl does not restrict you from anything, and in particular it doesn't restrict you from restricting yourself, if you're into that kind of thing. The sections Section 12.5.5, "Private Methods" and Section 12.7.5, "Using Closures for Private Objects" later in this chapter demonstrate how you can increase your dosage of discipline.

Admittedly, there's a lot more to objects than this, and a lot of ways to find out more about object-oriented design. But that's not our purpose here. So, on we go.

11.3. Overriding Built-in Functions		12.2. Perl's Object System

Copyright © 2002 O'Reilly & Associates. All rights reserved.