Lots of people swear by the book "Design Patterns". I am finding Object Oriented Perl to be a very useful book.
in reply to How to think.
The best advice I can give you is to do a lot of thinking, a bit of research on how objects are handled in other languages, and a lot of diagramming how real world things are put together.
For example, suppose you are designing a race track. You know you will need a track, cars, and spectators. What are the similarities of all of those things that you can generalize into a parent object? What are the differences (that matter to your application) that you want to list specifically in each object? Are there any special types of any object that would best be served by subclassing it?
Okay, it's not the greatest example, but if you do that for real-world things a few times, you'll get better at it. It helps to know exactly what kind of data you need now. Then worry about making it more flexible later.
- Track... no big thing here. Seems like a one-shot object.
- Cars... at the very least, things like acceleration, tires, and engines will be different. Maybe they each need to be subclassed, maybe they can just be member attributes.
- Spectators... size of hair, number of velvet Elvis paintings owned, days since last tornado, these can all be member attributes. Perhaps you can define subclasses for gender.