Slash Boxes
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 ]

TorgoX (1933)


"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

Journal of TorgoX (1933)

Wednesday January 16, 2002
06:49 PM

Are you too OO?

[ #2205 ]
Dear Log,

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 ..." in simple jargon-free terms.
    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.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • by ziggy (25) on 2002.01.16 19:03 (#3284) Journal
    Paul Graham has [] some interesting things to say about why OOP isn't especially useful in the general case, except for some obvious areas:
    • 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 :-), (2) it's easier to extend and (3) reuse as appropriate.

    (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...)