http://www.perlmonks.org?node_id=801851


in reply to Re: Questions from "Coders at Work"
in thread Questions from "Coders at Work"

There was a interesting difference of opinions on Design Patterns in the interviews; some have it high on their list, others dislike it and the cargo cult around it. I did something out of Design Patterns when I read it, but I was doing more C/C++ stuff at the time.

Replies are listed 'Best First'.
Re^3: Questions from "Coders at Work"
by apl (Monsignor) on Oct 18, 2009 at 13:48 UTC
    some have it high on their list, others dislike it and the cargo cult around it.
    I won't say I dislike it; rather, I don't believe every problem or solution can decompose as neatly as they describe. Professionally, I've always had to support the work of other people. So even if I don't worship at the altar of Design Patterns, I need to know what they are and how they work. And, after all, your question concerned what every programmer should read, not what they should agree with. 8-)
    I did something out of Design Patterns when I read it, but I was doing more C/C++ stuff at the time.
    Ditto.
Re^3: Questions from "Coders at Work"
by jakobi (Pilgrim) on Oct 18, 2009 at 14:47 UTC

    Isn't the main point about patterns a kind of contract with both parties hopefully understanding the meme in question identically? To allow selecting one approach as the default approach? To allow common/default assumptions?

    To allow reuse and communication with neither

    • drowning in verbose documentation, nor
    • the "normal" situation of having to reverse-engineer code for all but the most trivial usage (dusty-corners, there be dragons, you're not expected to understand this-comments)?

    So a team selecting a set of patterns to allow for default assumptions is a good thing (e.g. about large scale architecture, constraints, preferred approaches). Actually improving team (or CPAN author / module user) communication.

    A herd of small patterns all slightly different?

    Way too much of a good thing (cf. the missing default OO style for Perl5). So skimming a book introducing yet another set of patterns is good to obtain new tricks and approaches. But being a dictionary, such a book only offers a little help with the real problem: communication. And with Perl's expressivity (plus), many of the low-level acclaimed C++ patterns boil down to more or less single-line techniques (e.g. Schwartzian transform). Or lack direct applicability as we still didn't select a default OO style (minus - it's not helpful if a trivial one-line pattern requires 20 lines of interface glue to cope with both blessed hashes and blessed scalars).

    Now what is the set of patterns and assumptions that are safe to be assumed default/standard for random CPAN module ABC?

    Is selecting/migrating such defaults for OO or just CPAN modules only possible with a Revolution once in a while, with breakage of a scope similar to the Perl5-to-Perl6 situation?

    not really convinced about the most of the wave of pattern books (read: small-scale pattern dictionaries),
    Peter

    PS: TIMTOWTDI is great. But we can improve upon it, if we select one W as the (non-exclusive) default, to allow shortening the description of most of the variants to a small listing of differences: Situational awareness is a severely limited resource for me, and diffs waste less wetware capacity...
      Or lack direct applicability as we still didn't select a default OO style (minus - it's not helpful if a trivial one-line pattern requires 20 lines of interface glue to cope with both blessed hashes and blessed scalars).

      What are you thinking of here? OO code in Perl shouldn't care whether an object is a blessed hash, a blessed scalar, a blessed nuisance, inside-out, upside-down, a Moose, a Mouse, or even a C pointer with a thin XS wrapper. You have an opaque reference. You call methods on it without worrying what it points to.

      The only case I can immediately think of where this can legitimately fall down is when you inherit from someone else's object in a way that involves you trying to store additional private data inside their blessed data structure. But there are well-known ways to avoid that. And considering that code reuse through inheritance is a dodgy thing in the first place, the dodginess factor goes through the roof when you don't even control the code you're reusing!

      Maybe there are other cases where well-written code can go wrong, but all I can say is that I've never yet encountered any problems in Perl that I could attribute to the lack of a single official method of implementing objects. I may well be missing something, but this seems to me to be one of those things that is more about Perl being conceptually messy, than about that messiness causing real problems in practice.

        Thanx for your reply to my wondering :), Porculus!

        > What are you thinking of here? ... You have an opaque reference.

        Right: The opaque reference is what this situation practically results in. And right, it's code reuse/code inheritance with method overriding and attribute access that's the sore point. And again correct, one should be quite certain that non-blackbox-use is what one actually wants to do. But this is one valid way of the ways of TIMTOWTDI in Perl.

        And considering that code reuse through inheritance is a dodgy thing in the first place, the dodginess factor goes through the roof when you don't even control the code you're reusing!

        There's indeed a line of thinking to limit inheritance to interfaces at most, and especially not code. But I think the field's larger than that, also allowing for e.g. a kind of 'friend'/greybox-inheritance relationship, provided friends are cautious enough and do not trample all over each other's "name space".

        There's also the question of the interface offered by an object, including the kind of get/set methods it permits. Maybe even direct access. Wouldn't it be nice to just use Data::Dumper and that were enough to have the object itself tell us its set/get methods? Some kind of default assumptions of 'usually you do it that way' would be nice. Then one'd just need to check the doc's pitfalls section listing possible non-default caveats and exceptions. Less things to remember is a good thing TM.

        It's probably mostly a question of trust, assumptions, convenience and code reduction when subclassing.

        If you just use objects, then it's at most the get/set attribute issue. When composing objects w/o inheritance, its also pretty harmless. For real code inheritance with method overriding I think the idea I liked best was to stuff the extra data in a closure. But when you subclass and override a method, you'll normally want to minimize the code replication. And this definitely gets more than ugly/dodgy or rather fat, when you need to treat everything as opaque black boxes.

        > more about Perl being conceptually messy, than about that messiness causing real problems in practice

        With one exception (<> in one-liners), I actually like the messiness and TIMTOWTDI (incl. freedom of choice for possible OO-styles) and wouldn't wish to reduce it.

        Just specifying a primus-inter-pares among the OO-ways already in Perl5 would have been nice: kind of "and this is the default set of oo-memes for Perl, divergences from it are documented" (substitute "Pattern" or "Pattern-Language" if you wish); but w/o disabling any of the alternatives, please.

        This is IMHO one point where just the lower age of Python & Ruby (and thus their different/bolder/newer approach to OO) is enough to turn into a major sellingpoint for this pair of youngsters.