Chapter 15. Objects
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[*]. 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 and methods, nor where it will store its data, nor how its methods will mediate access to that data, nor what the class constructor will be called, nor what a method call will look like, nor how inheritance relationships will be declared, nor just about anything else. You can't even assume that there will be a class declaration (see the Class::Classless module, for example), or that the attributes or methods are specified at all (as in Class::Tables), or that object data isn't stored outside the program completely (like Cache::Mmap does), or that methods don't magically redefine themselves in derived classes when called a certain special way (as happens under Class::Data::Inheritable). This cornucopia of alternatives rarely results in robust or efficient code. Of the several dozen OO approaches most frequently used in Perl development, none of them scales well to the demands of large systems. That includes the consensus first choice: hash-based classes. This chapter summarizes a better approach; one that produces concise readable classes, ensures reliable object behaviour, prevents several common errors, and still manages to maintain near-optimal performance. |