When to use OO

In "Re: When to use perl", graff wrote:

Frankly, I don't believe that every piece of code needs to be An Instance of A Class or Object. Lot's of software requirements just don't lend themselves easily to that sort of abstraction, or at least can function quite well without it, thank you.

So... when do you think it's approppriate to use OO? Do you blend procedural programming with OO?

I know I do. I tend to use objects when there is data of which the internals are not too straightforward, and when I need more instances of them at the same time. For CGI, I wouldn't use OO, except when loading multiple form submissions in the same program at once — which very rarely happens.

For example, for a program I wrote, I have a module that splits formatted text into paragraphs, and paragraphs into lines (= where wordwrap occurs) all in order to determine how much screen layout the text takes. The story (= whole text), paragraphs and lines are objects. That came naturally to me. The rest of the program is mostly the standard procedural stuff.

And you?

Comment on When to use OO

Replies are listed 'Best First'.
Re: When to use OO by Aristotle (Chancellor) on Jun 01, 2003 at 12:08 UTC
You might be interested in Damian Conway's ten rules for when to use OO. :) Makeshifts last the longest.	[reply]
Re: When to use OO by larsen (Parson) on Jun 01, 2003 at 12:08 UTC
It's a recurring theme in Perlmonks, it seems: Where/When is OO useful?. HTH	[reply]
Re: When to use OO by sauoq (Abbot) on Jun 02, 2003 at 05:39 UTC
Do you blend procedural programming with OO? The dividing line between "procedural" and "object-oriented" isn't really that clear. I'm not sure an unambiguous definition for OOP even exists. Most (all?) OO languages can be thought of as a subset of procedural languages. Attempts to create "pure OO" languages haven't been overwhelmingly successful. Most (all?) of those provide some degree of support for procedural conventions. At the very least, OO and procedural languages both fall under the larger "imperative programming" heading (as opposed to logical and functional programming.) I prefer to think of OO as a natural extension of the procedural approach; the key enhancement being the association of procedures with the data they act on. OO is to data as structured programming is to flow control. So, yes. And underneath the covers, I use branches and loops in pretty much all of my class implementations... :-) -sauoq "My two cents aren't worth a dime.";	[reply]
Re: When to use OO by djantzen (Priest) on Jun 01, 2003 at 21:55 UTC
Yet Another Past Discussion: Perl oo vs plain Perl "The dead do not recognize context" -- Kai, Lexx	[reply]
Re: When to use OO by Juerd (Abbot) on Jun 01, 2003 at 12:23 UTC
Please do use Super Search next time :)	[reply]
Re: When to use OO by bobdeath (Scribe) on Jun 02, 2003 at 15:14 UTC
I personally think that one of the primary goal of OO programming is to seperate the interface from the implementation. This is a trademark of good design, and while it can be accomplished using procedurally, the use of inheritance and (in other languages) private/protected/public members helps to draw the line between interface and implementation more clear. For these reasons I try to us OO programming whenever I can.	[reply]