Perl Best Practices

Chapter 15. Objects

Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches.

— Paul Graham The Hundred-Year Language

Perl's approach to object orientation is almost excessively Perlish: there are far too many ways to do it.

There are at least a dozen different ways to build an object (from a hash, from an array, from a subroutine, from a string, from a database, from a memory-mapped file, from an empty scalar variable, etc., etc.). Then there are scores of ways to implement the behaviour of the associated class. On top of that, there are also hundreds of different techniques for access control, inheritance, method dispatch, operator overloading, delegation, metaclasses, generics, and object persistence.^[91] And, of course, many developers also make use of one or more of the over 400 "helper" modules from the CPAN's Class:: and Object:: namespaces.

There are just so many possible combinations of implementation, structure, and semantics that it's quite rare to find two unrelated class hierarchies that use precisely the same style of Perl OO.

That diversity creates a huge problem. The dizzying number of possible OO implementations makes it very much harder to comprehend any particular implementation, because the reader might not encounter a single familiar code structure by which to navigate the class definitions.

There is no guarantee of what a class declaration will look like, nor how it will specify its attributes ...