Re: Possible to create class at runtime if changes
Lothar Kimmeringer wrote:
The results from reflection can be kept in a cache. So all the
Method-, etc-instances don't need to be retrieved again and
again but can be done at startup of the application.
Lew wrote:
I worked on a project that tried this approach. The so-called "cache"=
was the
major source of concurrency bottlenecks for the whole application.
Sounded great in theory, looking at things from a single-threaded perspe=
ctive.
Not so great in practice, when multiple threads were trying to do real w=
ork
and getting hung up just on finding the method they were supposed to exe=
cute.
Lothar Kimmeringer wrote:
Sounds like a bad implementation of the cache, rather than a flaw
in the concept of caching results of reflection.
Well, yeah, of course, duhh. That's like saying any buggy program is
a bad implementation of the specs rather than a flaw in the concept of
the functionality overall. It's true, but not very useful in warning
people away from what makes the implementation bad.
On that particular project, I wound up with a slogan, "Anything that's
called a 'cache' in this project isn't." The parties responsible were
ostensibly good programmers with substantial experience. They just
wound up creating "a bad implementation of the cache" every time,
because they kept thinking single-threaded when the application was
run in a heavily concurrent environment.
The point is that it's easy to lose sight of things like concurrency
issues when you think you're enhancing performance, and this can
utterly defeat the intended purpose of the code section. "Oh, that's
just a bad implementation" begs the question of how the implementation
got to be bad in the first place. My example cautions programmers not
to be naive when they're "caching". In point of fact, they could have
sped the program up significantly by not optimizing the reflective
lookups prematurely.
They would have sped it up even further by abandoning reflection in
that particular project altogether.
Lew wrote:
Next time try object-oriented design and programming.
Lothar Kimmeringer wrote:
There are quite useful things you can solve by using reflection.
Plugin mechanisms are only one of these things.
And most of the time those are not the things people are trying to
solve when they use reflection.
You will note that I did not say that reflection is not useful.
However, it is fraught with peril, and many, many times when one is
using reflection heavily it turns out that it's overkill.
Most production plugin mechanisms I've encountered didn't need any
more reflection than 'Class#newInstance()'. Those that went beyond
that nearly always introduced multiple bugs by creating a "bad
implementation". Those cases all had alternatives available that
would have used very little if any reflection to supplement solid
object-oriented programming, but for some reason the coders avoided
those simpler, more robust idioms and screwed up what they did use.
Just because reflection is useful sometimes doesn't mean it's useful
all the time, and just because some reflection is useful at some time
doesn't mean that heavy use of reflection is useful at that time. To
a first order of approximation, proper object-oriented analysis and
programming will obviate the need for reflection beyond the occasional
'newInstance()' call.
--
Lew