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.
In reply to Re^2: Really Writing Object Oriented Perl
by aufflick
in thread Really Writing Object Oriented Perl
by agianni
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |