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.
Most program[er]s don't need OOP
ziggy on 2002-01-17T00:03:22
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...)
Re:Most program[er]s don't need OOP
chromatic on 2002-01-17T02:03:33
Ben Tilly has a functional parser for HTML tag-soup. It's fine stuff, but it might hurt your head at first, unless you're able to go toe-to-toe with MJD on a regular basis. :)
abstract classes!
ken on 2002-01-23T03:03:36
..
