13.9. Writing an Inheritable Class

Problem

You're not sure whether you've designed your class robustly enough to be inherited.

Solution

Use the "empty subclass test" on your class.

Discussion

Imagine you've implemented a class called Person that supplies a constructor called new , and methods like age and name . Here's the straightforward implementation:

package Person;
sub new {
    my $class = shift;
    my $self  = { };
    return bless $self, $class;
} 
sub name {
    my $self = shift;
    $self->{NAME} = shift if @_;
    return $self->{NAME};
} 
sub age {
    my $self = shift;
    $self->{AGE} = shift if @_;
    return $self->{AGE};
} 

You might use the class in this way:

use Person;
my $dude = Person->
new()
;
$dude->name("Jason");
$dude->age(23);
printf "%s is age %d.\n", $dude->name, $dude->age;

Now, consider another class, the one called Employee:

package Employee;
use Person;
@ISA = ("Person");
1;

There's not a lot to that one. All it's doing is loading in class Person and stating that Employee will inherit any needed methods from Person. Since Employee has no methods of its own, it will get all of its methods from Person. We rely upon an Employee to behave just like a Person.

Setting up an empty class like this is called the empty base class test ; that is, it creates a derived class that does nothing but inherit from a base class. If the original base class has been designed properly, then the new derived class can be used as a drop-in replacement for the old one. This means you should be able to change just the class name and everything will still work:

use Employee;
my $empl = Employee->
new()
;
$empl->name("Jason");
$empl->age(23);
printf "%s is age %d.\n", $empl->name, $empl->age;

By proper design, we mean using only the two-argument form of bless , avoiding any direct access of class data, and exporting nothing. In the Person::new() function defined above, we were careful to do these things. We use some package data in the constructor, but the reference to this is stored on the object itself. Other methods access package data via that reference, so we should be okay.

Why did we say the Person::new function  - is that not actually a method? A method is just a function that expects as its first argument a class name (package) or object (blessed reference). Person::new is the function that the Person->new method and the Employee->new method both end up calling. Although a method call looks a lot like a function call, they aren't the same. If you treat them as the same, very soon you'll be left with nothing but broken programs. First, the actual underlying calling conventions are different: method calls get an extra argument. Second, function calls don't do inheritance, but methods do.

Method Call

Resulting Function Call

Person->new()

Person::new("Person")

Employee->new()

Person::new("Employee")

If you got in the habit of calling:

$him = Person::
new()
;               # WRONG

you'd have a subtle problem, because the function wouldn't get an argument of "Person" as it is expecting, and so it couldn't bless into the passed-in class. Still worse, you'd probably want to try to call Employee::new() also. But there is no such function! It's just an inherited method call.

So, don't use function calls when you mean to call a method.

See Also

perltoot (1), perlobj (1), and perlbot (1); Chapter 5 of Programming Perl ; Recipe 13.1 ; Recipe 13.10


Previous: 13.8. Determining Subclass Membership Perl Cookbook Next: 13.10. Accessing Overridden Methods
13.8. Determining Subclass Membership Book Index 13.10. Accessing Overridden Methods