 |  |
13.3. Managing Instance Data
13.3.1. Problem
Each data attribute of an object, sometimes named data members or properties, needs its own method for access. How do you write functions that manipulate the object's instance data?
13.3.2. Solution
Either write pairs of get and set methods that affect the appropriate key in the object hash, like this:
sub get_name {
my $self = shift;
return $self->{NAME};
}
sub set_name {
my $self = shift;
$self->{NAME} = shift;
}or make single methods that do both jobs depending on whether they're passed an argument:
sub name {
my $self = shift;
if (@_) { $self->{NAME} = shift }
return $self->{NAME};
}When setting a new value, sometimes it may be useful to return not that new value, but the previous one:
# returns previously set value if changing it
sub age {
my $self = shift;
my $oldage = $self->{AGE};
if (@_) { $self->{AGE} = shift }
return $oldage;
}
$previous_age = $obj->age( $obj->age( ) + $TIME_PASSES );13.3.3. Discussion
Methods are how you implement the public interface to the object. A proper class doesn't encourage anyone to poke around inside its innards. Each data attribute should have a method to update it, retrieve it, or both. If a user writes code like this:
$him = Person->new( );
$him->{NAME} = "Sylvester";
$him->{AGE} = 23;then an argument could justifiably be made that they have violated the interface and so deserve whatever they get.
For nominally private data elements, you may omit methods that access them. However, then if—better make that when—you update the implementation, you'll need to scour the class to find where other methods within the class rely upon the particular representation that you're now changing. To be squeaky clean, you could have the class itself go through a mediated, functional interface to access instance data.
This extraordinary care isn't strictly required by the class of its own methods, but from the perspective of code that simply uses your module, it most certainly is. By mandating a strictly functional interface, you are free to alter your internal representation later without fear of breaking user code. The functional interface allows you to run arbitrary range checks and take care of any data reformatting or conversion.
Here's a fancy version of the name method that demonstrates this:
use Carp;
sub name {
my $self = shift;
return $self->{NAME} unless @_;
local $_ = shift;
croak "too many arguments" if @_;
if ($^W) {
/[^\s\w'-]/ && carp "funny characters in name";
/\d/ && carp "numbers in name";
/\S+(\s+\S+)+/ || carp "prefer multiword name";
/\S/ || carp "name is blank";
}
s/(\w+)/\u\L$1/g; # enforce capitalization
$self->{NAME} = $_;
}If users, or even other classes through inheritance, had been accessing the "NAME" field directly, you couldn't add this kind of code later. By insisting on only indirect, functional access to all data attributes, you keep your options open.
If you're used to C++ objects, then you're accustomed to being able to get at an object's data members as simple variables from within a method. The Alias module from CPAN provides for this, as well as a good bit more, such as the possibility of private methods that the object can invoke but folks outside the class cannot.
Here's an example of creating a Person using the Alias module. When you update these magical instance variables, you automatically update value fields in the hash. Convenient, eh?
package Person;
# this is the same as before...
sub new {
my $that = shift;
my $class = ref($that) || $that;
my $self = {
NAME => undef,
AGE => undef,
PEERS => [ ],
};
bless($self, $class);
return $self;
}
use Alias qw(attr);
our ($NAME, $AGE, @PEERS);
sub name {
my $self = attr shift;
if (@_) { $NAME = shift; }
return $NAME;
};
sub age {
my $self = attr shift;
if (@_) { $AGE = shift; }
return $AGE;
}
sub peers {
my $self = attr shift;
if (@_) { @PEERS = @_; }
return @PEERS;
}
sub exclaim {
my $self = attr shift;
return sprintf "Hi, I'm %s, age %d, working with %s",
$NAME, $AGE, join(", ", @PEERS);
}
sub happy_birthday {
my $self = attr shift;
return ++$AGE;
}You need to declare the package variables via our because Alias plays with package globals by the same names as the fields. To use globals while use strict is in effect, you have to predeclare them. These variables are localized to the block enclosing the attr invocation, just as though local were used on them. That means that they're still considered global package variables with temporary values.
13.3.4. See Also
perltoot(1), perlboot(1), perlobj(1), and perlbot(1); the section on "Managing Instance Data" in Chapter 12 of Programming Perl; the documentation for the Alias module from CPAN; Recipe 13.12
|  | |
| 13.2. Destroying an Object |  | 13.4. Managing Class Data |
Copyright © 2003 O'Reilly & Associates. All rights reserved.