Just IMO, but purity is for Evian. Do what works instead of what will make purists happy.
But that's a non-answer -- so a little more practical answer:
The way I've had the most success in programming OO is to diagram, diagram, diagram. Use a UML modeller or just paper and pencil, and encapsulate your types as classes, work out relationships between them, and add in methods as necessary.
You may need to do a number of iterations of your UML and an even greater number of process flowcharts before you lay down any code at all. The XP crowd is going to jump all over me, but I've had the most success when I do this, and then when first attacking the code I document first and flesh out later. I find it's most efficient to work out as many angles as possible ahead of time.
That being said, you'll always find more and more problems while coding, but building a good house starts with the foundation (your diagrams) and frames (your documented skeleton code). You can always retile the bathroom later.
Again, all just IMO.