Re^2: Really Writing Object Oriented Perl

I think the most troubling thing I see is actually the use of the "Blob anti-pattern" as you mention. We use classes, but only a few, and many of them are enormous. I'm struggling to figure out how to refactor these large classes, which is why I'm reading Fowler's book. But I also want to figure out how to write better OO code so I can avoid spending as much time in the refactoring process.

In the end, I suppose the best way is to just do it. And reading general OO books is my main plan, I was mostly wondering if there were any resources on Perl OO programming that focused on OO technique as much as or more than the technical aspects.

perl -e 'split//,q{john hurl, pest caretaker}and(map{print @_[$_]}(joi
+n(q{},map{sprintf(qq{%010u},$_)}(2**2*307*4993,5*101*641*5261,7*59*79
+*36997,13*17*71*45131,3**2*67*89*167*181))=~/\d{2}/g));'
[download]

Comment on Re^2: Really Writing Object Oriented Perl Download Code

Replies are listed 'Best First'.
Re^3: Really Writing Object Oriented Perl by doom (Deacon) on Jun 02, 2007 at 22:35 UTC
I'm struggling to figure out how to refactor these large classes, Okay, well you probably know this already, but a suite of automated tests really does help any sort of refactoring effort (OOP or not). You can split out functionality from one of the large blobs into smaller units, and then re-run the tests on the system to instantly get a pretty good idea if you've broken something. Most grand doctrines on software development ultimately strike me as at least 50% snake oil `[1]` by weight, but test-oriented programming is one of the few that I'm completely sold on. Caveat: when you've got lots of tests that check low-level routines, the tests become a kind of institutional weight on changing the way your primitives work. Any change in interfaces breaks your tests as well the code that uses what you've changed, so that's one more thing that needs attention. I don't see any thing to do about this but live with the pain: you really do need low-level tests, and perfectly designed interfaces that never need revision are a fantasy. As for general advice on working with Objects: Favor "aggregation" over inheritence if you can -- inheritence is always tempting as a way to share common- code, but it causes problems when you get too fancy with it. Avoid inheritence chains deeper than one or two levels (possibly: reserve inheritence for fixing design errors, avoid using it in initial designs). The notion that Objects are a "metaphor" doesn't really work: if you start off with a rule of thumb like "identify the nouns", you're likely to end up with something that's over-designed and that under-performs. My opinion (at the moment at least) is that it's best to just think about classes as bundles of routines that need access to the same data -- and it's perfectly okay to invent new abstractions that have no analog to some physical object (typically you need to come-up with bogo-nouns to convince people these are really "objects": "This is the Wangifier Handler Manager class"). I strongly suggest looking into the "Hash::Util" module (standard with perl 5.8.0), that provides "lock_keys" and "unlock_keys". You can use these with a hash-ref based object to lock down the existing field names, and help catch typos. Try grepping your codebase for things like "$self->{". That will help find places where someone cheated and peeked at the object href directly. Replace those with actual accessors. Off the top of my head, that's all I can think of... oh, maybe one more piece of advice: don't be a fanatic about pure-OOP. If it seems more natural to break out a standard operation as a proceedural module, there's no reason not to do that. And if you're working with a Real Relational Database (postgresql, oracle, etc) think about letting the database do some of the work (the class-to-table mapping popular with a lot of the ORM out there has it's problems -- though it probably does make for some quick prototyping). `[1]` Or some other animal product.	[reply] [d/l] [select]
Re^4: Really Writing Object Oriented Perl by Joost (Canon) on Jun 02, 2007 at 22:57 UTC
The notion that Objects are a "metaphor" doesn't really work: if you start off with a rule of thumb like "identify the nouns", you're likely to end up with something that's over-designed and that under-performs. My opinion (at the moment at least) is that it's best to just think about classes as bundles of routines that need access to the same data. My rule-of-thumb is to start out with your rule (routines that access the same data should be in the same object or class) and apply the relational database normal form rules to figure out which data needs to go where. After that, you may want to put "convenience methods" anywhere it's convenient and/or break the rules when it's needed. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^5: Really Writing Object Oriented Perl by herveus (Prior) on Jun 04, 2007 at 11:27 UTC
Howdy! This database designer approves heartily of that approach. OO modeling looks an awful lot like database normalization with a few wrinkles thrown in. On Flyweights... (with sneaky segue to data modeling) was a moderately productive meditation on this that I wrote four years ago. yours, Michael	[reply]
Re^3: Really Writing Object Oriented Perl by john_oshea (Priest) on Jun 02, 2007 at 20:24 UTC
The Perl Design Patterns wiki is worth a look if you've not come across it already.	[reply]


more useful options
	PerlMonks