All the Perl that's Practical to Extract and Report
use Perl Log In
TorgoX (1933)
sburkeNO@SPAMcpan.org
http://search.cpan.org/~sburke/
"Il est beau comme la retractilité des serres des oiseaux rapaces [...] et surtout, comme la rencontre fortuite sur une table de dissection d'une machine à coudre et d'un parapluie !" -- Lautréamont
Are you too OO?
I took the various separate components of the new Pod parser I wrote (a base class for this, a derived class for that, etc.), and finally plugged them together last night, and ran a test on a Pod "Hello World" document. It works! It's just minor cleanup work now.
Yes, I said "classes". It's object-oriented. I thought a great deal about whether I wanted it to be that object-oriented -- by no means do I consider OO to be the default (much less "correct") way to do things. It has its definite advantages at times, and I sure don't mind having the interface that module users see be nice and OO. But when I sense that the OOiness is taking on a mind of its own as I'm writing the internals, then I know things are going in the wrong direction.
How to know if what you're writing is too object-oriented:
- It's probably too OO if you're making a whole slew of subclasses, and you spend more time trying to get the class hierarchy "just right", than time it's likely to save because it's "organized" or "simple". You may strongly resist arriving at that appraisal ("but it'll be fab if it's organized JUST SO!"), but be prepared to chalk up your desires as being a subconscious drive to neo-Platonism. (BTW, read that book! It will make your smarter, and maybe even cleverer.)
- It's probably too OO if your module doesn't really do anything until the user writes a subclass of it. That's almost always a really bad sign. (Extra bad if you don't include a good worthwhile working example of such a subclass.)
- It's probably too OO if each object has only one attribute, and/or only one method besides its constructor.
- It's probably too OO if you can't finish the sentence "An object of this class represents a
Good examples: an object of this class represents a loan. An object of this class represents an FTP session.
Necessary-evil examples: an object of this class represents a response to an HTTP request. An object of this class represents a "cookie jar", an aggregate of HTTP cookies. An object of this class represents a lexicon for a human language. An object of this class represents an in-progress parse of some data, and you pump it to get more tokens out of the parse, or push more data to it, or whatever.
Bad examples: An object of this class represents a factory object for classes which make factory objects which make accessors.
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
Most program[er]s don't need OOP (Score:3, Interesting)
- Fixing languages that are fundementally broken (lacking closures, for example)
- "Naturally" object oriented systems (CAD, Window managers, etc.)
- large teams of mediocre programmers in large companies
- large companies where make-work is desirable (look at all of the effort we're putting into this project!)
That said, an object oriented Pod parser is probably the way to go, mostly because (1) you've put a lot of effort into it already(One of these days, it would be nice to see what a functional foo parser would look like, and see if that would be significantly better measured against some meaningful axis...)
Reply to This
Re:Most program[er]s don't need OOP (Score:2, Informative)
abstract classes! (Score:1)