Curiosity about reflection

  • Thread starter Thread starter Harlan Messinger
  • Start date Start date
H

Harlan Messinger

I've been surprised by the frequency with which I've seen online
inquiries regarding reflection, but perhaps I shouldn't be. I would have
thought that the primary, if not sole, "legitimate" purpose in using
reflection (where by "legitimate" I mean without violating or
circumventing good coding practices) is to create development tools. Is
it that the inquiries I see are commensurate with the number of people
who are building development tools, or is it that a lot of the inquiries
indicate people using reflection for purposes where it isn't the right
tool? Or is it that there are plenty of other "legitimate" uses of
reflection? If so, can someone enlighten me?
 
Reflection is likely sometimes overused, I convinced someone recently to use
an interface for a plug-in style app, previously he used reflection not only
to find the class (it has to be the only class in the assembly) but also to
perform the call to this class instance. Using an interface is much simpler.

But also it could be just that as it can be tricky and a less familiar area
someone that really needs reflection will perhaps more likely ask for help
than when using other well know areas...

IMO you generally can't draw conclusion from what you see in the wild. You
just see the tip of the iceberg, not the whole picture (if you see a product
forum full of posts, is this because the product is bad or because this is
the product everyone uses and you see just those who have a problem ?)...
 
I've been surprised by the frequency with which I've seen online
inquiries regarding reflection, but perhaps I shouldn't be. I would
have thought that the primary, if not sole, "legitimate" purpose in
using reflection (where by "legitimate" I mean without violating or
circumventing good coding practices) is to create development tools.
Is it that the inquiries I see are commensurate with the number of
people who are building development tools, or is it that a lot of the
inquiries indicate people using reflection for purposes where it isn't
the right tool? Or is it that there are plenty of other "legitimate"
uses of reflection? If so, can someone enlighten me?
Click to expand...


1. Genericizing apps
2. Emitting classes that are created on the fly
3. Discovering more about undocumented code (this is a tool issue)
4. Learning (also a tool issue)
5. Reverse Engineering (also a tool issue)
6. Certain types of "late binding"

In an ideal world, we would call many of these "illegitimate" practices,
but we don't live in an ideal world. ;-)

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
[...] Is it that the inquiries I see are commensurate with the number of
people who are building development tools, or is it that a lot of the
inquiries indicate people using reflection for purposes where it isn't
the right tool? Or is it that there are plenty of other "legitimate"
uses of reflection? If so, can someone enlighten me?
Click to expand...

It's some of the second two. There are lots more valid uses for
reflection than just development tools. But yes, there are a number of
people who stumble across reflection and look to it to solve their
problems, when in fact they should be solving their problem some other way.

To some extent, for these people reflection is a crutch. They run into a
wall where they don't have the OOP design skills required to come up with
a good OOP solution, so they resort to reflection to break into the
encapsulation the language and framework is trying to provide for them.
Of course, in the process they abandon all of the code quality and
maintenance benefits that the programming environment is providing for
them.

And on top of that, reflection is almost always less efficient and more
prone to hard-to-fix bugs.

Pete
 
Good OOP and reflection can go hand in hand. Like a lot mentioned earlier
use of OO patterns solves many many problems, but then there are times that
you really need to use it. ASP.NET databinding is an example.

Another example is a Factory pattern that is used to load a strategy, what
happens if you want to extend the strategy without recompiling, with the use
of reflection and interfaces/strategy pattern you could load a strategy at
runtime. Be sure that you do not constantly load the assembly tho and use
clone/copy to create new instances of the strategy once loaded.

Like everyone has said reflection is expensive.
 
Back
Top