(This isn't intended as a flame war, but I'm interested in hearing other
opinions on the subject.) I would disagree with *some* of these sentiments.
>1) Reuse is the Big Lie of the OO world; often claimed as a benefit, but
>rarely realized.
>
I'm not sure if I agree with this; granted, the overhyped goal of "Tinkertoy
Programming" hasn't emerged, but then again, the real OO pundits (and not
the trade rags) never really promised anything of that sort to begin with.
It is a benefit, when it works (C and C++ Standard Libraries, for example),
it works well. By the same token, I wouldn't label "reuse" as an OO-only
concept--C was working on reuse for decades (anybody remember .libs?) before
C++ came along.
>2) Components (well, VBXs and OCXs) have been more successful than
>library-based
>reuse. (Presumably, this is because they are built using fairly
standardized
>idioms
>(properties, events, and methods), expose a relatively simple and
>well-defined
>user interface, and are binary compatible with a very popular family of
>development
>environments.)
>
Aren't components simply more opaque objects? Components, IMHO, wouldn't
have emerged had people not started seeing the deficiencies in "current" OO
implementation and methodology.
>3) Building reusable code demands more up-front effort.
>
Absolutely true. What's more, it demands much more in the way of up-front
design, and most organizations aren't forward-thinking enough to see the
payoffs involved in putting that effort in up front.
>4) Once you've built your reusable components, the _real_ trick is to get
>someone
>else to reuse them.
>
Also absolutely true; this is why most process patterns papers I've read
(and personal and anecdotal evidence backs up) claim that for the best reuse
within an organization, an individual needs to be allocated towards
promoting and spreading the reuse Gospel; call them your "Reuse Architect",
if you will. Simply placing components (or objects, it makes little
difference) into a common repository doesn't net you anything, if nobody
knows what's in there and whether they can tweak or otherwise modify/use an
existing component to meet their needs.
>#4 is really more of a social/organizational problem than a technical one,
>but it's probably
>the biggest reason that reuse doesn't work as well in practice as it does
in
>theory
>. If your organization's IT efforts are balkanized hackfests where
>cross-team
>communication never occurs, it's wishful thinking to expect to get more
>than
>a trivial level of reuse.
>
Actually, I see them *all* as a social/organizational problem, since reuse
itself is technology-independent. (C'mon, let's admit it--you *can* reuse VB
code, if it's done properly, and the same holds true for Perl, C, and even
"HTML languages" like ColdFusion, ASP or even HTML itself, assuming your Web
Server supports some form of server-side include.)
It's also possible to achieve reuse within the team; granted, this won't net
the kinds of payoffs that one might enjoy were this to take place across the
corporation, but sometimes, management requires a working, living example of
the benefits of an approach or technology before they can get behind it.
Start with just yourself--build a collection or library of reusable code,
objects, or components, and reuse as much as possible. Others will notice,
start to contribute and use, and before too long, the entire team will be
honed in on it. Once the team is, other teams might start to notice, and
suddenly, you're giving a brown-bag seminar at lunch one day on what you've
done within your team, so others can benefit.
Granted, that's an idealized scenario, but every line of code you can reuse,
is a line of code you *don't* have to rewrite, cut&paste, or debug.
>IMHO, of course.
>
Ditto.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
