[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emperor's new clothes - ACM followup.
I think Jim and Andrzej both missed Dyke's point. Of course tools like
OO have their value IN RESTRICTED AREAS: for instance, OO is excellent
(apparently) for point-and-click menu applications with lots of
screens. It was a "tool to manipulate data" that bollixed it.
In restricted areas? The greater moiety, as far as I'm concerned.
If you don't know where you're going, then Perl is an excellent way
forward. If you have (and/or need) a plan, or a map, then only a
structured (don't misread that word) approach will do.
OO is so knowledge-centralized that using it on any assembly of
truly independent components tends to suffocate the project in
Proper use of encapsulation and abstraction will do the trick every
time (almost by definition). Add in the courage to refactor, and the
knowledge of when to throw something away, plus some project
I have been involved in at least two projects that
ground to a halt this way (one was revived in C, the other in
Perl). A data flow design with truly independent (running)
components is not only quickly completed, but also documents itself
for the developer entering 6 months later (I'm doing exactly this
at the moment). Because all information passes through channels
instead of hierarchies.
You're really not talking about the base (OO) technology at all, but
its (possibly misguided and unskilled) application.