Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: perl OO - to use or not to use

by leriksen (Curate)
on Sep 15, 2003 at 05:22 UTC ( #291488=note: print w/replies, xml ) Need Help??

in reply to perl OO - to use or not to use

A few questions I like to ask myself when deciding on the split between procedural and OO
  • how many classes am I likely to write - if it is < 3 perhaps procedural is better
  • are there obvious inheritance relationships - '... and this report is just like that one, except that it doesn't have a totals section' - if there are, OO seems a stronger approach
  • what are the odds of the original code needing several changes/additions in future - would small objects help make these changes easier to introduce
  • would an object acting out a pattern of behaviour make the code easier to use/develop - e.g. I like to model processing record-based files with an iterator like pattern
    while (defined (my $record = $file_object->next()) { # next creates a +record object from data in the file $records->process(); }
  • do I need flexibility in applying my objects ? Will this be easier/clearer in OO or procedural ? e.g.
    # OO $object->fold()->spindle()->mutilate(); #procedural my $rc = mutilate(spindle(fold($data)));
  • if you have the knowledge - are patterns (ala GoF) going to help - these well-known solutions generally seem better in OO contexts, but that is not always so
  • how many methods will these classes have - perhaps lots of single function objects would be better as a library of functions - unless these classes are overriding specific portions of a parent class (specialising their interface)

there are no hard-and-fast rules - except that the more experience and knowledge you have, the better your decisions will be. So, in the beginning, you can expect to make bad decisions - but as long as you view them as learning examples, then making them can be seen as encouraging.

Replies are listed 'Best First'.
Re: Re: perl OO - to use or not to use
by dragonchild (Archbishop) on Sep 15, 2003 at 14:02 UTC
    This may just be my take on the world, but I haven't yet found a non-trivial application that would be better written in procedural vs. OO. (OO vs. functional is an interesting debate, but I'm still trying to figure out where pure procedural is indicated.)

    Now, I do tend to write a lot of scripts, like CGI scripts. The script itself is procedural, but it will use a lot of objects. Let's face it - a non-trivial web app is going to have a lot of similar functionality in each one of its scripts. The following is an incomplete list:

    • database connectivity
    • template usage
    • parameter validation
    • business rules

    As such, those make sense to be put into objects. Some would say modules work just as well, but I always seem to run into the "Widgets are just like gizmos, except for ..." situation. Or, I do a lot of factoring, for which abstract base classes are eminently suited. So, I almost always start my designs with an OO flavor, tossing in functional and procedural as needed.

    We are the carpenters and bricklayers of the Information Age.

    The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      To some extent I agree with you - very few non-trivial applications are easier/better in procedural vs OO (and I agree with you on the functional approach too - but just try writting a useful Haskell version of a nontrivial app - sheesh!!). It just depends on how wide your values for non-trivial are :-)
      I find I use procedural approach heavily in the startup of an app development, and once that is humming, focus on the OO from then on. E.g. I usually focus procedurally during the startup of my app on
      • reading parameters (using Getopt::Long exclusively)
      • setting up logging (using Log::Log4perl exclusively)
      • setting up filehandles (using IO::File exclusively)
      • setting up timing/stats
      • when required, setting up DBI (using DBI)

      after that I start doing the decomposition dance
      oh, and btw, I make it a rule never to write the same code twice in an app - I always factor out to a sub or method. This help highlight new candidates for classes/modules faster. And if I notice that much of the code is avariation on a theme, I stop and try to find some abstraction that allows me to parametize that code.
      I think it was Donald Knuth who said
      Every problem in computer science can be solved with either more - or less - abstraction. Experience tells you which one of those to apply.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://291488]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2018-07-20 02:55 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (422 votes). Check out past polls.