Message from discussion reusable software components
From: "John Roth" <johnr...@ameritech.net>
Subject: Re: reusable software components
Date: Mon, 15 Oct 2001 11:08:00 -0700
Organization: Posted via Supernews, http://www.supernews.com
References: <firstname.lastname@example.org> <C8Jr7.94133$Hm.email@example.com> <firstname.lastname@example.org> <3BB0860A.7BEFABD1@efinnet.com> <3BB2A38E.email@example.com> <3BB2AD41.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <9qeamr$nmqn9$1@ID-75294.news.dfncis.de> <firstname.lastname@example.org>
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
"Robert C. Martin" <rmar...@objectmentor.com> wrote in message
> Code is certainly part of the context. I have seen "reusable"
> frameworks fail because the code was not a good fit. However, the
> context also includes the development environment, the execution
> environment, and the problem domain.
That's certainly true. There's a great set of articles on exactly
this problem in the new CACM (Communications of the ACM)
on Aspect Oriented Programming.
The biggest issue in generic code reuse is that working code
tends to deal with a number of real world issues that have little
or nothing to do with the core application area. For example,
in your heavy duty math library, how much really has to do with
the math, and how much with error handling, which in turn has
more to do with the error handling model in the compiler libraries?
If the domain is, for example, credit bureau records, how much
has to do with the security model? Where is that code? Why it's
tangled in with everything else. Why? Well, you can't very
well check with an access object unless you have some code to
find the object and call a method, and that code has to be in
the core component.
Initialization code for an application tends to be one huge
ball of tangled concerns. I'm coming to the conclusion that
"spaghetti code" is only one aspect of the more pervasive
anti-pattern that I will call "spaghetti design."
If a method or object deals with more than one aspect of
an application, then it has to know about multiple aspects,
which automatically makes it less reusable. However, if it
only deals with one aspect, it's not all that useful. Therein
lies the problem.
AOP looks like it might be a way to deal with it, or at
least think about it. Time will tell...