When should I use OO Perl?

Question

Hi, All.

I'm just learning Perl.

When is it advisable to use OO Perl instead of non-OO Perl?

My tendency would be to always prefer OO unless the project is just a code snippet of < 10 lines.

TIA

Answer 1

I don't think you should measure it by lines of code.

You are right, often when you are just writing a simple script OO is probably too much overhead, but I think you should be more flexible regarding the 10 lines aproach.

In all cases when you are using OO Perl Rememebr to use Moose (or Mouse)

Answer 2

Damian Conway has a passage in Perl Best Practices about this. It is not a rule that you have to follow it, but it is probably better advice that I can give without knowing a lot about what you are doing.

Here is the publisher's page if that is a better place to link to the book.

Answer 3

There is a good discussion about same subject @ PerlMonks.

Having Moose certainly makes it easier to always use OO from the word go. The only real exception is if compilation start-up is an issue (Moose does currently have a compile time overhead).

/I3az/

Answer 4

This question doesn't have that much to do with Perl. The question is "when, given a choice, should I use OO?" That "given a choice" bit is because in some languages (Java, for example), you really don't have any choice.

The answer is "when it makes sense". Think about the problem you're trying to solve. Does the problem fit into the OO concepts of classes and object? If it does, great, use OO. Otherwise use some other paradigm.

Perl is fairly flexible, and you can easily write procedural, functional, or OO Perl, or even mix them together. Don't get hung up on doing OO because everyone else is. Learn to use the right approach for each task.

All of this takes experience and practice, so make sure to try all these approaches out, and maybe even take some smaller problems and solve them in multiple ways to see how each works.

Answer 5

From Damian Conway:

10 criteria for knowing when to use object-oriented design

---

1. Design is large, or is likely to become large

2. When data is aggregated into obvious structures, especially if there’s a lot of data in each aggregate

   For instance, an IP address is not a good candidate: There’s only 4 bytes of information related to an IP address. An immigrant going through customs has a lot of data related to him, such as name, country of origin, luggage carried, destination, etc.

3. When types of data form a natural hierarchy that lets us use inheritance.

   Inheritance is one of the most powerful feature of OO, and the ability to use it is a flag.

4. When operations on data varies on data type

   GIFs and JPGs might have their cropping done differently, even though they’re both graphics.

5. When it’s likely you’ll have to add data types later

   OO gives you the room to expand in the future.

6. When interactions between data is best shown by operators

   Some relations are best shown by using operators, which can be overloaded.

7. When implementation of components is likely to change, especially in the same program

8. When the system design is already object-oriented

9. When huge numbers of clients use your code

   If your code will be distributed to others who will use it, a standard interface will make maintenence and safety easier.

10. When you have a piece of data on which many different operations are applied

    Graphics images, for instance, might be blurred, cropped, rotated, and adjusted.

11. When the kinds of operations have standard names (check, process, etc)

    Objects allow you to have a DB::check, ISBN::check, Shape::check, etc without having conflicts between the types of check.