Further examples

The preceding example illustrates that it is not too difficult to convert a function-oriented interface to an object-oriented one. What the example doesn't illustrate is why you would want to. In this section we are going to explore some aspects of object-oriented to hopefully show how such an interface can have advantages in approaching problems.

The fundamental item of interest when using an object-oriented interface is the object created with the new method - as well as giving you access to various methods, this object can also be used to tie, in a very fundamental way, the data used in the problem to the methods that act upon it. Consider the following variation of the RGB2 module of before:

package RGB3;
use strict;

sub new {
    my ($class, $rgb) = @_;
    my $self = {rgb => $rgb};
    bless $self, $class;
    return $self;
}

sub rgb2hex {
    my $self = shift;
    my $rgb = $self->{rgb};
    my $hex = sprintf("%02X%02X%02X", $rgb->[0], $rgb->[1], $rgb->[2]);
    return $hex;
}

1;

which is used in a script as

use strict;
use RGB3;
my @rgb = (255, 255, 255);
my $color = RGB3->new(\@rgb);
my $hex = $color->rgb2hex();
print "The hexadecimal equivalent is $hex\n";

What we have done here is called the new method with an argument - the reference to the @rgb array - and then in the new method made within the hash reference $self a key rgb with a value $rgb. When bessed into the class, this data then becomes an integral part of the object. Thus, we no longer have to pass the data into methods, as it is available through the object $self passed into the method (in this case, as $self->{rgb}).

This unification of data and methods serves two important purposes:

• conceptually, it ties together data and methods, so that the programmer is aware at a fundamental level which methods operate on which data,
• practically, it can help in cutting down on incorrect usage, by minimizing the amount of arguments passed into methods - one just passes explicitly the data in once, into the new method, and after that the methods have automatic access to it, without relying on the user to pass it in.

Let us examine a more complicated problem. Suppose instead of converting the rgb form of a color to hexadecimal, we wanted to convert a hexadecimal form to an rgb triplet. For this we can use the Perl code

    my @rgb = map {hex($_) } unpack 'a2a2a2', $hex;

for a color specified in hexadecimal form $hex. We could make up, in analogy with RGB3, another module that took as its data a color in hexadecimal format and supplied a method, hex2rgb, to convert that into an rgb format. What we are going to do now is extend RGB3 to take as data a color in either format and supply both conversions.

package RGB4;
use strict;

sub new {
    my ($class, %args) = @_;
    my $self = {rgb => $args{rgb}, hex => $args{hex}};
    bless $self, $class;
    return $self;
}

sub rgb2hex {
    my $self = shift;
    return $self->{hex} if defined $self->{hex};
    my $rgb = $self->{rgb} or die "No rgb data available";
    my $hex = sprintf("%02X%02X%02X", $rgb->[0], $rgb->[1], $rgb->[2]);
    $self->{hex} = $hex;
    return $hex;
}

sub hex2rgb {
    my $self = shift;
    return $self->{rgb} if defined $self->{rgb};
    my $hex = $self->{hex} or die "No hex data available";
    my @rgb = map {hex($_) } unpack 'a2a2a2', $hex;
    $self->{rgb} = \@rgb;
    return \@rgb;
}

1;

This can be used in a script as

use strict;
use RGB4;
my @rgb_data = (255, 255, 255);
my $hex_data = 'FFFFFF';

my $obj1 = RGB4->new(rgb => \@rgb_data);
my $hex = $obj1->rgb2hex();
print "The hexadecimal equivalent is $hex\n";

my $obj2 = RGB4->new(hex => $hex_data);
my $rgb = $obj2->hex2rgb($hex);
print "The rgb equivalent is @$rgb\n";

This illustrates some new features worth noting:

• in the new method, the data is passed in through an %args hash; this makes it easier in the script to know what is being passed in, as one uses explicit keys, rather than relying on some order of the arguments.
• in the methods, after doing the calculation, we store the calculated value in the object $self. In these methods we then initially check to see if the data to be calculated is available already in $self, and if so, we return that value, rather than calculating it again.
• in the methods, we also put in a check on whether the data needed to do the calculation is available, and if not, we immediately die, rather than proceed with the calculation. This makes for error messages that are easier to understand, as sometimes bugs in a program results from errors that occur many lines previous to where a reported error occurs.
• the script also illustrates that one can have multiple objects (instances) of a class in the same script, each with its own data.

This example shows a bit of the power of thinking about a problem in terms of objects - the object can hold a multitude of data concerning a problem, and this data is readily accessible within the methods.