Is Perl code mainly written in object-oriented-design?

Question

Since there is for almost everything a module and it is repeatedly said that we should not reinvent the wheel and since I do not write modules for CPAN I have no need to use OO. But my question is, is professional Perl code mainly written in OO-style?

Answer 1

In short, only if you want code-reusability and readability; for writing simple system scripts or code to perform one task, then it's kind of a waste, especially if it's the kind of thing that's not going to be well-documented. When writing a complex program, for example, it really helps to organize one's thoughts and to modularize the problem by writing a series of, well, modules. The benefits of using object-orientation increase exponentially when working on a project with more than one developer.

Answer 2

Most of the Perl code I write is small-size scripts and I never use OOP for them, even if they use CPAN modules that are OOP-designed. For the larger code projects, I tend toward OOP about 70% of the time but it depends: is the code going to be used for a long time? If it's likely to stick around and many users will be dipping their spoons in the mix, OOP is probably a better design.

Answer 3

OO-Design is not a "silver bullet". There is no harm in writing code that is not-OO. It's just the "popular" choice. As someone once said (and I paraphrase):

OO-design simply had a better marketing group

This is just stemming from the fact that people believe "most code" should be OO. Of course, you can keep track of state "internally in an object", but it'll also get people doing silly things inside of the object that make things more complicated too.

My problem is with "most code written in OO". I believe there should be a healthy balance between Objects and Functions. Functions can operate on Objects.

There are plenty of things that don't lend themselves to objects very well.

Answer 4

If you are Writing a simple script to do some relatively simple processing, file modification etc. its ok to go with a non OO design but in my experience if your script is going to be around longer and is potentially doing things that you may one day want to reuse in another script or in a different context than what you planned for its best to go with the OO approach. In general its also much easier to scale and enhance an OO based design.

Especially when it comes to representation of data of any kind. Once you've written a class to represent that data, it is very convenient to add useful methods to that data class(such as display, check, analyze, reset, write to file, load from file etc.).

This also has a positive side-effect of making your scripts much less verbose and easy to read and maintain since a lot of the details of operation on the data are left to the class methods. If you are dealing with large sets of data its also a lot easier to deal with arrays of objects rather than with hashes which you will probably end up using a lot if you dont have an OO design.

In the future if you have to write a script to process the same data in a different way, you can simply reuse the data classes in a different script. If your data happens to be a little different so that you need to add more fields or more methods. no problem simply extend the original data class.

The best reference for learning OO Perl that I've found is : Object Oriented Perl: A Comprehensive Guide to Concepts and Programming Techniques by Damian Conway. One of the things I struggled with when I started to do OO Perl is that there are so many different ways to do it. Eventually I just settled on one and have stuck with it over the years.

Answer 5

I see OOP primarily as a way to bind and set of behaviors to a data structure. Any time my data structures look like they will get complicated, I compose objects.

This helps to centralize and abstract the code related to manipulating the data. Which in turn reduces duplicated code and simplifies refactoring. The same things could be achieved using purely procedural code. I find that OOP makes the relationship explicit and easier to conceptualize in an intuitive way.

Consider this structure:

my $foo = {
    meezle => [qw( a d g e l z )],
    twill  => {
        prat => 'qua',
        nolk => 'roo',
    },
    chaw => 7,
    mubb => [ 123, 423,756, 432 ],
    ertet => 'geflet',
};

When I wind up with a struct like this (nested and non-uniform), I start thinking "object". I get certain when I find myself writing lots of code to access, modify and validate data in the structure.

Since most non-trivial projects require non-trivial data manipulations, I use objects for at least some part of most jobs.

I may or may not go all-out in my OOP. Usually there are a few things that aren't objects. There may or may not be an application base class. Some elements may be handled as normal procedural code. Some may include functional approaches. It all depends on what makes sense given the requirements of the project.

The most important thing to remember is that your code must be clear to the poor schmuck tasked with maintaining it. (It could be you in 6 months, newly wakened from a deep 4am, sleep, with your boss's boss's boss screaming at you to fix the damn software before the company is bankrupted.)