Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Object Oriented Programming - OOP in Perl

When would you need to learn how to write Object Oriented code in Perl?

Case 1.

You can accomplish a lot by using Perl in a procedural way, writing statements, functions, and even moving out some functions to modules. At one point you'll encounter a module that is itself written in the Object Oriented paradigm. In order to use that module you'll need to learn a slightly different syntax. It is still not Object Oriented programming, but it is already using some classes and instances.

As you create more complex projects you might start to feel that you need a better organization of your data and functions. One such solution would be to convert some of your code to Object Oriented Perl.

Case 2.

You get tasked to maintain a project that was already written in Object Oriented Perl and now you need to understand the internal working of the classes.

Vocabulary

OOP or Object Oriented Programming is not the same in every programming language. Each implementation has its own features. However there is a mostly common vocabulary. I wrote "mostly" as even the vocabulary used for various features of OOP might differ among programming languages. Let's see what are the words usually used:

  • class (The blueprint of a collection of data and actions on that data. In python it is referred to as 'class object')

  • instance (As in an instance of the class. Sometimes it is called an object. In python it is called an 'instance object'.)

  • members (the collective name of attributes and methods)

  • attributes (values, the data, basically internal variables)

  • methods (actions, basically functions working with the data in the class or the instance. There are both class and instance methods)

  • accessors (getters and setters, a subset of the methods that will allow the user to read or change the content of attributes)

  • constructor (A specialized method to create the structure of an instance from a class.)

  • initializer (A specialized method to fill the initial values of an instance after it was created by the constructor.)

  • destructor (A method to clean up the mess after we are done using an instance.)

  • inheritance (A way for a specialized class to reuse features of a more generic class.)

  • polymorphism (The idea that different classes might have identically named attributes or behaviors that are somehow related.)

  • encapsulation (It is the concept of hiding the internal parts of a class from the external world.)

  • singleton (A design pattern to ensure that a class has only one instance.)

WWW::Mechanize, and example using OOP

Let's take a look at an example of using a Perl module which was written in Object Oriented style. I am quite sure you have encountered many similar modules. We are looking at the WWW::Mechanize module that makes it easy to send HTTP requests to web servers.

This is the full code:

use strict;
use warnings;
use feature 'say';
our $VERSION = '0.01';

use WWW::Mechanize;

my $url = shift @ARGV or die "Usage $0 URL";
# say $WWW::Mechanize::VERSION;


my $mech = WWW::Mechanize->new(autocheck => 0);
my $res = $mech->get($url);
say $res->status_line;
say $mech->status();
say $mech->res->status_line, "\n";

$mech->dump_headers();
say '';

if ($mech->success) {
    print $mech->content;
}

We can use it on the command line by passing

$ perl demo.pl https://httpbin.org/get

200 OK

Status: 200
200 OK

Connection: close
Date: Sun, 22 Jun 2025 12:40:45 GMT
Server: gunicorn/19.9.0
Content-Length: 271
Content-Type: application/json
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Client-Date: Sun, 22 Jun 2025 12:38:26 GMT
Client-Peer: 34.198.95.5:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Amazon/CN=Amazon RSA 2048 M02
Client-SSL-Cert-Subject: /CN=httpbin.org
Client-SSL-Cipher: ECDHE-RSA-AES128-GCM-SHA256
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Version: TLSv1_2

{
  "args": {}, 
  "headers": {
    "Accept-Encoding": "gzip", 
    "Host": "httpbin.org", 
    "User-Agent": "WWW-Mechanize/2.19", 
    "X-Amzn-Trace-Id": "Root=1-6857f9cd-788661eb40c56ecd14d4d272"
  }, 
  "origin": "46.120.8.126", 
  "url": "https://httpbin.org/get"
}

$ perl demo.pl https://httpbin.org/status/500

500 INTERNAL SERVER ERROR
500
500 INTERNAL SERVER ERROR

Connection: close
Date: Sun, 22 Jun 2025 12:41:15 GMT
Server: gunicorn/19.9.0
Content-Length: 0
Content-Type: text/html; charset=utf-8
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Client-Date: Sun, 22 Jun 2025 12:38:56 GMT
Client-Peer: 18.209.97.55:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Amazon/CN=Amazon RSA 2048 M02
Client-SSL-Cert-Subject: /CN=httpbin.org
Client-SSL-Cipher: ECDHE-RSA-AES128-GCM-SHA256
Client-SSL-Socket-Class: IO::Socket::SSL
Client-SSL-Version: TLSv1_2

HTTP::Response

A warning

One of the problems I see when teaching new things to programmers is tha they get a bit too enthusiastic and they will start to use the new knowledge everywhere.

I am sure you remember when you first learned regular expressions and then you wanted to use it everywhere, including parsing of HTML.

So I'd like to tell you up-front that OOP is not the solution to every problem.

We saw this very clearly when in the mid '90s with the introduction of Java people started to use OOP and specifically inheritance everywhere.

The well known example was the representations of houshold items. cats and dogs. As both cats and dogs are mammals it sounded like a good idea to create a class called "Mammal" and to make the class "Cat" and the class "Dog" both inherit from that class. After all there are a lot of common features between cats and dogs. This was fine. However later that also wanted to represent other things around the house, chairs and tables.

At that point some overly enthusiastic person noticed that both chairs, tables, cat, and dogs have leggs. So they created a class call "LeggedThings" and made all 4 classes inherit from that.

In the name of code-reuse and DRY they created a totally unmaintainable mess.

Of course one does not need OOP to create an unmaintainable mess, but OOP is also just a tool. One needs to weight various possible solutions and makes sure nothing is overused.