Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

heusserm (4461)

heusserm
  (email not shown publicly)
http://www.xndev.com/
AOL IM: MatthewHeusser (Add Buddy, Send Message)
Matt Heusser is JAPH and an XP-Er [xprogramming.com]. (The Methodology, not the Operating System.) Right now, he's doing a lot of Test Driven Development in Perl.

Journal of heusserm (4461)

Monday September 08, 2003
01:01 PM

Container Classes In Perl: Revisited

[ #14585 ]
I got a couplea interesting comments to my post on container classes in perl.

Both of them seemed to make the same arguments "In Large systems ... you are going to need it ... better to do it earlier than later."

Who every said I was designing a large system? And the rest of it just doesn't sound agile enough to me. No, you AIN'T Gonna Need it.

In other words, I think you don't need a container class until you actually need a container class. (Did I say, you're NOT gonna need it yet?)

When behavior starts to creep into your data structure, you risk not Just Doing It Once, so you re-factor into a class. I'm just writing in opposition to premature OO-ification - the root of a couplea kinds of evil. :-)

List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Container Classes In Perl: Revisited 6 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I think you're blindly following a rule here. Sure you might not need it right now, but don't go and design yourself down a dead end. I like to have two lists of features; features we need right now, and features we are going to need soon. You don't want achive something in the first list at the expense of making something in the second very hard.

    Doing the simplest thing possible in a lot of cases is to just return a hash of data. I've found that if you return a blessed hash with proper methods (using C
  • Perl makes this sort of stuff so easy. Generating a quickie little class is trivial, given that there's lots of helper modules on CPAN for it, and you can roll your own with code generation (at runtime) in about 10-15 lines anyway!

    So since it's so easy, why not just do it?
  • You're dead right at one level. My rule of thumb for this is that as soon as I start to manipulate an anonymous array or hash in more than one module then it's time to turn that anonymous structure into its own class. And if I find myself monkeying with it in three modules then that's a definite code smell.
  • I'm not sure I'm qualified to respond to the words of someone with such a high
    GPA, but here goes:

        Though inheritance is usually needless complexity, and functional programming
        with ADTs is the One True Way, using packages in Perl *is* still very
        convenient. It lets you push the functions on your ADT into the namespace of
        that package, instead of having one huge function namespace. So instead of
        oparate_on_foo($foo) and operate_on_bar($
  • Who every said I was designing a large system?

    This is true. However, I think I can clarify -- if your code needs to be maintained and there is a chance that it might need to be extended in the future, then a little work up front will pay off big time. By putting the behaviours in a class you can avoid action-at-a-distance that might apear later. And yes, 'You Ain't Gonna Need It' is a valid comment. But then again, XP isn't a dogma, its a good starting point.

    When behavior starts to creep into your da
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.