Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^2: Really Writing Object Oriented Perl

by agianni (Hermit)
on Jun 02, 2007 at 13:20 UTC ( #618906=note: print w/replies, xml ) Need Help??


in reply to Re: Really Writing Object Oriented Perl
in thread 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));'

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.

      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.

        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
Re^3: Really Writing Object Oriented Perl
by john_oshea (Priest) on Jun 02, 2007 at 20:24 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://618906]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (9)
As of 2018-12-19 16:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How many stories does it take before you've heard them all?







    Results (85 votes). Check out past polls.

    Notices?