Excellent advice++ Every word.

Use OO when OO makes sense, but don't try and force fit everything into the OO-model. OO is a means to an end--and just one of several--not an end in itself.

Don't ignore the built-in facilities. They're simpler, faster and usually better thought through than most people can write themselves at their first, second or third attempt. Use them and get on with the job, rather than stressing that it's "not OO".

Don't fuss that the 'bad man' might be able to access your private attributes and methods. Half the time you'll be the potential 'bad man', and if you choose to break encapsulation, you'll do it for good, expendient or deadline driven reasons. The other half of the time, the 'bad man' will be a collegue who's hit a wall that your interface specification didn't consider and he'll consult you for the workaround, And thank your lucky stars that you can when you need to. Go with the flow and improve the interface when time and budget allow. Working, coupled code today is worth 10 times, perfectly decoupled code a month or two from now. If only because it allows you time to discover it's functional shortcomings, early enough to correct them.

Don't try to predict the future--you'll always get it wrong. Write what you need today, and re-write what you have to, tomorrow. In this imperfect world, the re-write will happen anyway, but in most cases the code you re-write will be a big improvement over anything you could have written today. You'll know more about the problem and more about the solution.