To OO or not to OO

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

Hi, Object oriented programming in perl has been something I am doing for a while and have done some useful programming, faster programming.
Yet there are programs which comes when I tend to do non-OO way and it works fine for the moment, even few additional changes I can accomodate without much difficulties.
More are the changes, and I feel that OO way should have my life easier in the first place.
Thinking initially about OO seems not to be paid well in terms of thinking and spending the time in OO way.
Some good example of OO programming would be useful, which involves simple data operations.

Thanks,
Artist

Comment on To OO or not to OO

Replies are listed 'Best First'.
Re: To OO or not to OO by petdance (Parson) on Jan 08, 2002 at 00:02 UTC
See Damian Conway's ten rules for when to use OO. xoxo, Andy -- <megaphone> Throw down the gun and tiara and come out of the float! </megaphone>	[reply]
Re: To OO or not to OO by Masem (Monsignor) on Jan 07, 2002 at 23:51 UTC
Remember that OO is not a magic cure for every programming problem. While nearly every problem can be cast into an OOP solution space, the result may be less efficient or harder to maintain than in a different programming mode (such as procedural or functional). Knowing when and when not to use OOP is one of those things that comes from experience. There's a few weak guidelines, but these certainly aren't hard or set. One that I believe works that I've mentioned before is to sit down for no more than 5 minutes, undistracted, and write out a basic OOP class structure for the problem, not necessarily completing the class design, but trying to make sure all parts of the problem can be put into OOP terms. If, after 5 minutes, you cannot see how to put certain pieces together in an OOP style, then most likely you should consider doing the code in procedural style. On the other hand, if a OOP structure drops out nicely, then OOP is probably the way to go. In generally, anything involving user interaction in which the end results cannot be predicted without knowledge of the user interaction, OOP is the way to go; when you are simply running scripts that have fixed input from other sources, it might be better to stick to a procedural output. This does not mean you can't use small snippets of OOP classes to aid in that, but if you are looking for efficiency, you will most likely be better suited to a simple producural system. But again, knowning where the draw the line here is something that comes with working in the field for a long time. ----------------------------------------------------- Dr. Michael K. Neylon - mneylon-pm@masemware.com \|\| "You've left the lens cap of your mind on again, Pinky" - The Brain "I can see my house from here!" It's not what you know, but knowing how to find it if you don't know that's important	[reply]
Re: To OO or not to OO by merlyn (Sage) on Jan 07, 2002 at 23:47 UTC
OO doesn't seem to pay off until you can start using encapsulation or inheritance. That's about 500 to 1000 lines of code on your own, or 5 lines if you're using an OO module. -- Randal L. Schwartz, Perl hacker	[reply]
Re: To OO or not to OO by Ineffectual (Scribe) on Jan 08, 2002 at 02:48 UTC
I tend to use OO a lot because I run two sites that are duplicate in every respect with a different dataset in the database. This makes it easier to write a library and pass in a username rather than have duplicate copies of scripts and things like that. Just my 2c. Ineffectual	[reply]