It seems that every introduction to Object Oriented Code these days has a "container class."
You know, a class that holds other classes. Something described in "Design Patterns" by the Gang Of Four (GOF).
The thing is, you often don't need one in perl.
Perl has two built-ins that meet the need for this: Hash and Array. Arrays probably meet the need the best.
They are as big as you need them to be.
You can push and pop them.
You have two built-in ("Free") iterators: For and Foreach.
You have random-access by index, and length functions.
Why would anyone "need" a container class (by default) when you can just declare an anonymous array?
Sure, there might be specific times when a container class would be nice - when you are doing some complex HTML slicing again and again, for instance. In that case, go ahead, use a container.
But, in general, I think a container class is a purist, or "perfectionist" ideal that may not add practical value, yet will increase lines of code. And lines of code adds a maintenance burden.
So, I would argue that, in perl, in general, use arrays instead of writing container classes.
Thoughts?
Re:Thoughts?
james on 2003-09-08T17:16:19
pdcawley does echo my thoughts on this. In large systems often you don't want to just be push'ing on or pop'ing from an array. You want to be doing things like validation of values that are being push'ed and pop'd.
If you want to be doing validation then you want to ensure that you Don't Repeat Yourself. You also want to make sure that the behaviour is close to the data. In short, you want a class.
For sure, with Perl, you could tie the Array or Hash, but, there is a problem with that. First, Tie'ing is slow. But I'm not going to worry about that one too much. Secondly, and most importantly, you are limited to the operations that Perl provides you with (push, pop, shift, unshift, splice, etc..) and almost undoubtably when you are dealing with data there is behaviour that goes beyond 'just adding an element to the array'. Third, re-read the second point:)
Perl provides a really good abstraction of the behaviour that an array needs to exhibit, but don't kid yourself... at some point in the future you'll need to exhibit some behaviour as well, and that is when you'll need a container class, and the sooner you have that container class, the happier you'll be.
The popular statically typed languages often have difficulty with containers because they have to fit into the static typing scheme. (Of course, if you're using a weakly typed language such as Java or C, you can just cast to the appropriate void and cast back, if you aren't bothered by such things as good taste.)
Thankfully, Perl avoids that route, caring only about the container type, as references fit into scalars.
Re:Typesafety
jordan on 2003-09-08T19:16:45
I think Dominus covers this well in a talk he did for a Perl Conference.
Pay special attention to 4, 5 and 6.
ObFanBoyStatement: Dominus is so cool. Who else has the courage to point out that those who parade around in Design Patterns for Software are naked?
Re:Typesafety
pdcawley on 2003-09-09T04:43:14
Lots of people. Doesn't make 'em any more right though. Just because the Gang of Four book is not a good patterns book doesn't mean that patterns have no value. Take a look at Kent Beck's Smalltalk Best Practice Patterns for a superb example of a pattern language. Martin Fowler's Refactoring is also a great patterns book.
The GoF book isn't a pattern language, it's just a collection of 'words'.
