Firstly, go get yourself some real OO fun with Smalltalk. You can get a traditional smalltalk environment for free (Squeak) and a lot of excellent Smalltalk texts are online, also for free (free smalltalk books). Doing smalltalk has really helped me "think in OO" much more than I used to.

Having said that, don't then write OO Perl the way you would write OO Smalltalk. There are two key reasons why I say that.

Firstly, Perl offers many useful constructs beyond OO that it would be silly to ignore. For instance, don't use a collection class when an array will do. For another example, when you have a problem that lends itself to functional programming, using Perl's functional style will be more succinct, powerful and faster than OO.

Secondly, and this is a genuine reason, is that of all the things perl does really quickly, method calls is not one of them. Sub calls are slow, method calls are *really* slow. What this means is that when you have two roughly equivalent design choices, one which would result in 1,000 method calls and another that would result in 50 - in perl I would always choose the latter.

A general way of thinking that I have come up with is to use strict OO concepts at class boundaries, ie. APIs, but within the class only using OO where it makes sense. This allows you, IMO, nearly all of the classic OO benefits, while retaining Perl's expressiveness and performance.

If you want to learn a great way to design OO class boundaries and APIs, I suggest Domain Driven Design by Eric Evans - it's one of the best software related books I have ever read.

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.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."