in reply to Really Writing Object Oriented Perl

Can you tell us what kind of "code smells" you've observed, and also, can you tell us if you've seen any evidence they're really causing you problems? Compliance with doctrine isn't the ultimate goal, of course...

The one abuse-of-objects practice that I've seen really cause problems is "the Blob anti-pattern": one of the few things I really like about "Objects" is they way they handle encapsulation, and if you've got everything shoveled into one namespace, it hardly matters if you call that namespace an "object" or a "bloated script".

In general, I've been coming to the conclusion that having a nice barrage of automated tests is the key thing: compared to that, every other issue (choice of language; design patterns; OOP/proceedural; inside-out, upside-down or sideways, etc) is nearly insignificant.

(Though I don't think "Test First" programming isn't strictly necessary, "Test Soon" is good enough.)

  • Comment on Re: Really Writing Object Oriented Perl

Replies are listed 'Best First'.
Re^2: Really Writing Object Oriented Perl
by agianni (Hermit) on Jun 02, 2007 at 13:20 UTC

    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]
[reply]
[d/l]
      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]
        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]
[reply]

In Section Seekers of Perl Wisdom