OO code split

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

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.	[reply]
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.	[reply]
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	[reply]
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.	[reply]