Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

OO code split

by melguin (Pilgrim)
on Sep 12, 2001 at 02:50 UTC ( [id://111826]=perlquestion: print w/replies, xml ) Need Help??

melguin has asked for the wisdom of the Perl Monks concerning the following question:

I am currently learning object oriented programming in Perl (the only language I know decently) and am trying to apply it to a project I'm working on. I have a growing program file that I want to split up.

I have subroutines that do searches, adds, edits, cataegorizing, etc., and thought of breaking up the code that way. However, it seems that in order to make it true OO each module should deal with making and modifying a data object. Is this true?

Also, if I'm doing a split into modules, is it best to go OO or should I break it another way?

melguin.

Replies are listed 'Best First'.
Re: OO code split
by chromatic (Archbishop) on Sep 12, 2001 at 03:11 UTC
    Unfortunately, this is the sort of question that can only be answered with experience. Do you have some sort of model where you can separate data and behavior into discrete objects? Do you find yourself passing the same kind of information in and out of your functions?

    There's nothing wrong with using Exporter sanely. If you can split things up into modules, and some of them don't immediately lend themselves to object orientation, don't force it.

    Hmm, this doesn't seem like a very helpful answer. I guess my rule of thumb is, "Use OO when it makes things easier." You can certainly accomplish the same kinds of things in a purely-procedural language as with a functional or an object oriented language. The question is one of relative ease.

Re: OO code split
by thpfft (Chaplain) on Sep 12, 2001 at 03:41 UTC

    My best rule of thumb here is a very vague one: is there a thing?

    it's not a very sensible rule, i know, but my experience has been that it's not worth working in an OO way unless some entity in your program is asking you to do it.

    or to put it another way: if your central data structure is a hash, then it's quite likely that oo will help. if it's a hash of hashes, then read perltoot right away. otherwise, perhaps not.

    Damian Conway's rules are much better than mine, as you would expect.

Re: OO code split
by bikeNomad (Priest) on Sep 12, 2001 at 05:26 UTC
    It is hard to make an existing procedural program into a good OO one (at least if it's of any size). You will probably get some benefit from encapsulation and modularity if you break your program up into packages, but that won't make it OO.

    Object oriented programs are not designed around data and operations on that data, no matter whether the operations are separated into modules that only deal with a single kind of data or not. That model (data and procedures that operate on data) is the basis of the procedural model, independent of packaging and data hiding.

    Instead, object oriented design models a program as a community of collaborating entities (objects), each with their own responsibility. These objects don't have to have any data at all; they might just provide behavior.

    The problem with converting from a procedural program to an OO one is that the problem decomposition happens differently: structured procedural programs are designed by breaking down the overall task into subtasks and introducing data as needed by the subtasks. OO ones are designed starting with object interactions first.

    I ran across a good article that discusses this difference from an educational point of view, and suggests that object oriented concepts should be presented before procedural ones. You can find it here: Why Procedural is the Wrong First Paradigm if OOP is the Goal

Re: OO code split
by dragonchild (Archbishop) on Sep 12, 2001 at 16:29 UTC
    Note, that OO can apply not just to things that are a certain class, but also things that do a certain class. Sorta the difference between "be-ers" and "do-ers". Thus, you can create an entire OO-hierarchy for objects that sort, search, or whatever. Maybe that might be useful for your thinking.

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://111826]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (6)
As of 2024-03-29 09:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found