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