I\'m trying to understand object orientation. I understand it a little bit of course, but sometimes I\'m not 100% clear. How do you decide what should be turned into an object (
When deciding if something is an object or not, ask yourself if it has the following ...
State
Does the candidate have significant state? If it doesn't then all of the methods on it are likely to be only weakly related. In this case you've probably identified a library of module of reusable functions.
Behaviour
Does the object actually do something in the domain? For example is it just full of accessors which manipulate a struct or record.
Identity
Does the object really exist within the domain as an identifiable entity? Is there some innate aspect of the entity which distinguishes it from similar other entities? The door handle is an example - it doesn't really have identity since one door handle is likely to be the same as another.
If you answer no to some of these then you probably don't have an object - and that's fine a library or module can be a valuable reusable artifact
Above all, don't worry about it ...
I also wouldn't worry too much about the reuse aspect of this. Designing class hierarchies is like designing scalable software - it's too easy to optimise early. Sketch out a design on a piece of paper and if you can, validate the design with a few hand-drawn interaction diagrams. You'll find that over time you'll develop a real insight into what's really valuable and reusable.