Related
Say I have a bunch of classes that implement an interface:
public interface IBuilding
{
string WhatAmI();
}
Class house:IBuilding
{
string Ibuilding.WhatAmI(){return "A House";}
}
Class Skyscraper:IBuilding
{
string Ibuilding.WhatAmI(){return "A Skyscraper";}
}
Class Mall:IBuilding
{
string Ibuilding.WhatAmI(){return "A Mall";}
}
And then I want to dynamically choose what to instantiate the class:
enum buildingType { house, Skyscraper, Mall };
string someMethodOrAnother()
{
string building= textboxBuildingType.Text;
Ibuilding MyBuildingClass;
buildingType UserSelectedClass = (buildingType) Enum.Parse(typeof(buildingType), building);
if (Enum.IsDefined(typeof(buildingType), UserSelectedClass) )
{
MyBuildingClass = (some code that dynamically creates a class instance);
}
else
{
MyBuildingClass = new house();
}
return MyBuildingClass.WhatAmI;
}
Now I could do this in a switch statement, but I thought I had found a more elegant technique. Or is the whole idea of using an interface wrong? Perhaps I need a delegate instead?
In general, I would use a Dictionary with Activator.CreateInstance:
Dictionary<buildingType, Type> typeMap = new Dictionary<buildingType, Type>()
{
{ buildingType.House, typeof(House) }
}
IBuilding building = (IBuilding)Activator.CreateInstance(typeMap[userSelection]);
If this were WPF, you could use a converter to do this directly from the view to the view model.
If I understand what you're trying to do correctly, there are several ways to go about this but at the end of the day you'll have to have some logic that picks one particular type from a list of available types.
Some options (not an exhaustive list):
Use reflection to inspect your assemblies and determine what types implement the interface you want.
Use dependency injection (like LightInject) to do the assembly inspection for you and give you a list of types you can instantiate. DI libraries have various features to control how to discover types. This is a very flexible solution and the work is done for you.
Use an XML file (or other file format) to describe types that can be used. This is not very flexible but it allows you to list the types you want to be available regardless of what's in the assemblies. (Obviously, you can't make a non-existent type available but you can hide existing types without recompiling the code.)
At the end, you'll end up with a list of types that implement the interface you need. With the list you have to implement some kind of logic to actually pick one particular type that you'll instantiate - this logic is specific to your application (maybe pick the type based on a list in a listbox, etc.): no one can tell you how to do this.
Once you pick the type, you can just use Activator.CreateInstance() to create an instance of the type you picked. Alternatively, if you use LightInject, you can ask the library to return an instance of the specific type for you.
I am trying to create a web-based tool for my company that, in essence, uses geographic input to produce tabular results. Currently, three different business areas use my tool and receive three different kinds of output. Luckily, all of the outputs are based on the same idea of Master Table - Child Table, and they even share a common Master Table.
Unfortunately, in each case the related rows of the Child Table contain vastly different data. Because this is the only point of contention I extracted a FetchChildData method into a separate class called DetailFinder. As a result, my code looks like this:
DetailFinder DetailHandler;
if (ReportType == "Planning")
DetailHandler = new PlanningFinder();
else if (ReportType == "Operations")
DetailHandler = new OperationsFinder();
else if (ReportType == "Maintenance")
DetailHandler = new MaintenanceFinder();
DataTable ChildTable = DetailHandler.FetchChildData(Master);
Where PlanningFinder, OperationsFinder, and MaintenanceFinder are all subclasses of DetailFinder.
I have just been asked to add support for another business area and would hate to continue this if block trend. What I would prefer is to have a parse method that would look like this:
DetailFinder DetailHandler = DetailFinder.Parse(ReportType);
However, I am at a loss as to how to have DetailFinder know what subclass handles each string, or even what subclasses exist without just shifting the if block to the Parse method. Is there a way for subclasses to register themselves with the abstract DetailFinder?
You could use an IoC container, many of them allows you to register multiple services with different names or policies.
For instance, with a hypothetical IoC container you could do this:
IoC.Register<DetailHandler, PlanningFinder>("Planning");
IoC.Register<DetailHandler, OperationsFinder>("Operations");
...
and then:
DetailHandler handler = IoC.Resolve<DetailHandler>("Planning");
some variations on this theme.
You can look at the following IoC implementations:
AutoFac
Unity
Castle Windsor
You might want to use a map of types to creational methods:
public class DetailFinder
{
private static Dictionary<string,Func<DetailFinder>> Creators;
static DetailFinder()
{
Creators = new Dictionary<string,Func<DetailFinder>>();
Creators.Add( "Planning", CreatePlanningFinder );
Creators.Add( "Operations", CreateOperationsFinder );
...
}
public static DetailFinder Create( string type )
{
return Creators[type].Invoke();
}
private static DetailFinder CreatePlanningFinder()
{
return new PlanningFinder();
}
private static DetailFinder CreateOperationsFinder()
{
return new OperationsFinder();
}
...
}
Used as:
DetailFinder detailHandler = DetailFinder.Create( ReportType );
I'm not sure this is much better than your if statement, but it does make it trivially easy to both read and extend. Simply add a creational method and an entry in the Creators map.
Another alternative would be to store a map of report types and finder types, then use Activator.CreateInstance on the type if you are always simply going to invoke the constructor. The factory method detail above would probably be more appropriate if there were more complexity in the creation of the object.
public class DetailFinder
{
private static Dictionary<string,Type> Creators;
static DetailFinder()
{
Creators = new Dictionary<string,Type>();
Creators.Add( "Planning", typeof(PlanningFinder) );
...
}
public static DetailFinder Create( string type )
{
Type t = Creators[type];
return Activator.CreateInstance(t) as DetailFinder;
}
}
As long as the big if block or switch statement or whatever it is appears in only one place, it isn't bad for maintainability, so don't worry about it for that reason.
However, when it comes to extensibility, things are different. If you truly want new DetailFinders to be able to register themselves, you may want to take a look at the Managed Extensibility Framework which essentially allows you to drop new assemblies into an 'add-ins' folder or similar, and the core application will then automatically pick up the new DetailFinders.
However, I'm not sure that this is the amount of extensibility you really need.
To avoid an ever growing if..else block you could switch it round so the individal finders register which type they handle with the factory class.
The factory class on initialisation will need to discover all the possible finders and store them in a hashmap (dictionary). This could be done by reflection and/or using the managed extensibility framework as Mark Seemann suggests.
However - be wary of making this overly complex. Prefer to do the simplest thing that could possibly work now with a view to refectoring when you need it. Don't go and build a complex self-configuring framework if you'll only ever need one more finder type ;)
You can use the reflection.
There is a sample code for Parse method of DetailFinder (remember to add error checking to that code):
public DetailFinder Parse(ReportType reportType)
{
string detailFinderClassName = GetDetailFinderClassNameByReportType(reportType);
return Activator.CreateInstance(Type.GetType(detailFinderClassName)) as DetailFinder;
}
Method GetDetailFinderClassNameByReportType can get a class name from a database, from a configuration file etc.
I think information about "Plugin" pattern will be useful in your case: P of EAA: Plugin
Like Mark said, a big if/switch block isn't bad since it will all be in one place (all of computer science is basically about getting similarity in some kind of space).
That said, I would probably just use polymorphism (thus making the type system work for me). Have each report implement a FindDetails method (I'd have them inherit from a Report abstract class) since you're going to end with several kinds of detail finders anyway. This also simulates pattern matching and algebraic datatypes from functional languages.
I would like to write code without a lot of switch, if/else, and other typical statements that would execute logic based on user input.
For example, lets say I have a Car class that I want to assemble and call Car.Run(). More importantly, lets say for the tires I have a chocie of 4 different Tire classes to choose from based on the user input.
For the, i dunno, body type, letS say i have 10 body type classes to choose from to construct my car object, and so on and so on.
What is the best pattern to use when this example is magnified by 1000, with the number of configurable parameters.
Is there even a pattern for this ? Ive looked at factory and abstract factory patterns, they dont quite fit the bill for this, although it would seem like it should.
I don't think the factory pattern would be remiss here. This is how I would set it up. I don't see how you can get away from switch/if based logic as fundamentally, your user is making a choice.
public class Car {
public Engine { get; set; }
//more properties here
}
public class EngineFactory {
public Engine CreateEngine(EngineType type {
switch (type) {
case Big:
return new BigEngine();
case Small:
return new SmallEngine();
}
}
}
public class Engine {
}
public class BigEngine : Engine {
}
public class SmallEngine : Engine {
}
public class CarCreator {
public _engineFactory = new EngineFactory();
//more factories
public Car Create() {
Car car = new Car();
car.Engine = _engineFactory.CreateEngine(ddlEngineType.SelectedValue);
//more setup to follow
return car;
}
}
The problem you tell of can be solved using Dependency Injection.
There're many frameworks implementing this pattern (for example, for .NET - excellent Castle.Windsor container).
I think elder_george is correct: you should look into DI containers. However, you might want to check the builder pattern (here too), which deals with "constructing" complex objects by assembling multiple pieces. If anything, this might provide you with some inspiration, and it sounds closer to your problem than the Factory.
You can get around having to use a lot of if or switch statements if you introduce the logic of registration in your factory, a registration entry would add a binding to your dictionary in your factory:
Dictionary<Type,Func<Engine>> _knownEngines;
In the above line, you bind a type to a factory function for example like so:
private void RegisterEngine<TEngineType>(Func<T> factoryFunc) where TEngineType : Engine
{
_knownEngines.Add(typeof(TEngineType), factoryFunc);
}
This would allow you to call:
RegisterEngine<BigEngine>(() => new BigEngine());
on your factory
So now you have a way of allowing your factory to know about a large number of engines without needing to resort to if/switch statements. If all your engines have a parameterless constructor you could even improve the above to:
public void RegisterEngine<TEngineType>() where TEngineType : Engine, new()
{
_knownEngines.Add(typeof(TEngineType), () => new TEngineType());
}
which would allow you to register your engines that your factory can create like so:
RegisterEngine<BigEngine>();
Now we simply need a way of associating a user input to the right type.
If we have some sort of enumeration then, we might might want to map the enum values to their corresponding type. There are many ways to achieve this, either with a dictionary in a similar way as we have done already, but this time it is an enum as a key and a type as a value or by decorating the enum values with their corresponding type as demonstrated here (If you have a very large number of values, this possibility could be interesting)
But, we can skip all this and just take a shortcut and associate the enumeration with the factory function directly.
So we would make our Dictionary look like this:
Dictionary<MyEngineEnumeration,Func<Engine>> _knownEngines;
You would register your engines
public void RegisterEngine<TEngineType>(MyEngineEnumeration key) where TEngineType : Engine, new()
{
_knownEngines.Add(key, () => new TEngineType());
}
like so:
RegisterEngine(MyEngineEnumeration.BigEngine);
And then you would have some sort of create method on your factory class that takes your enumeration value as key:
public Engine ResolveEngine(MyEngineEnumeration key)
{
// some extra safety checks can go here
return _knownEngines[key]
}
So your code would set your
Car.Engine = EngineFactory.ResolveEngine((MyEngineEnumeration)ddlEngine.SelectedValue)
You could follow the same pattern with wheels and so on.
Depending on your requirements, following a registration/resolution approach would allow you to potentially configure your available engines externally in an xml file or a database and allow you to make more engines available without modifying the release code file but by deploying a new assembly which is an interesting prospect.
Good luck!
You could use something like this:
Define a class representing an option within a set of options, ie. a TireType class, BodyType class.
Create an instance of the class for each option, get the data from a store. Fill a collection, ie TireTypeCollection.
Use the collection to fill any control that you show the user for him to select the options, in this way the user selects actually the option class selected.
Use the obejcts selected to build the class.
If any functionality requires chnges in behavior, you could use lamdas to represent that functionality and serialize the representation of the code to save it the store; or you could use delegates, creating a method for each functionality and selecting the correct method and saving it into a delegate on object creation.
What I would consider important in this approach is that any option presented to the user is fully functional, not only a list of names or ids.
You can try the policy class technique in C++.
http://beta.boost.org/community/generic_programming.html#policy
Are you simply asking if you can create an instance of a class based on a string (or maybe even a Type object)?
You can use Activator.CreateInstance for that.
Type wheelType = Type.GetType("Namespace.WheelType");
Wheel w = Activator.CreateInstance(wheelType) as Wheel;
You'd probably want to checking around the classes that you wind up creating, but that's another story.
I've written a resolver so I can have a very primitive DI framework. In the framework I allow for a dependency resolver to specify what default types to load if nothing is specified or registered.
However, the way I do the default loading has got me wondering. I'm not sure I'm doing it the best way it could be done.
Example:
T LoadDefaultForType<T>()
{
T _result = default(T);
if (typeof(T) == typeof(ISomeThing)
{
result = new SomeThing();
}
... more of the same
else
{
throw new NotSupportException("Give me something I can work with!");
}
return _result;
}
Update
The use of this would be to get the default object for a given interface in the event that a module or assembly has not configured the interface with a concrete type.
So for instance:
IoC.Resolve<ISomeThing>();
would need to return back to me a SomeThing object if nothing else has been registered to ISomeThing. The LoadDefaultForType in this case is kind of a last ditch effort to use a default (in this case whatever my domain model is).
The Resolve might shed some light on this as well:
T Resolve<T>()
{
T _result = default(T);
if (ContainedObjects.ContainsKey(typeof(T))
_result = (T)ContainedObjects[typeof(T)];
else
_result = LoadDefaultForType<T>();
return _result;
}
Any thoughts? Is there a better way to load default types given that I'm trying to allow for a Convention Over Configuration approach?
A few of suggestions:
You could create an attribute that can be used to mark the default implementation type of a particular interface. When you attempt to resolve the type, you could search for this attribute on T and use reflection to dynamically instantiate the type.
Alternatively, you could use reflection to search the available (loaded) assemblies or a concrete type that implements the interface. This can be a slow and expensive processes, so it would only make sense if the default case is rare.
Finally, if you're comfortable with naming conventions, you could search for a class that has the same name as the interface but without the leading "I". Not the best approach, but certainly one that can be made to work in a pinch.
public T LoadDefaultForType<T>()
where T : new()
{
T _result = new T();
return _result;
}
the code above would be a better way, but im not sure what it is your're trying todo, more information would help give u a better way of doing whatever it is you're trying to achieve.
I suggest taking a look at Unity for dynamically loading types, ie. Dependency injection
Neil's approach is the best if T can be resolved (I think it also has to be in the same assembly?).
Within your class, you could create an internal "registry" of sorts that could be used with System.Reflection to instantiate items without the giant switch statement. This preserves your "convention over configuration" while also keeping you DRY.
Edit
Combined with one aspect of LBushkin's answer to show some working code. (At least, it compiles in my head, and is taken from an example that I know works...)
public T LoadDefaultForType<T>()
{
try
{
string interfaceName = typeof(T).AssemblyQualifiedName;
// Assumes that class has same name as interface, without leading I, and
// is in ..."Classes" namespace instead of ..."Interfaces"
string className = interfaceName.Replace("Interfaces.I", "Classes.");
Type t = Type.GetType(className, true, true);
System.Reflection.ConstructorInfo info = t.GetConstructor(Type.EmptyTypes);
return (T)(info.Invoke(null));
}
catch
{
throw new NotSupportException("Give me something I can work with!");
}
}
Note that - as written - it won't work across assembly boundaries. It can be done using essentially the same code, however - you just need to supply the assembly-qualified name to the Type.GetType() method. (fixed - use AssemblyQualifiedName instead of FullName; assumes that interface and implementing class are in same assembly.)
One way would be to have a list of AssemblyQualifiedName pairs, with the first containing the base type and the second containing the child to be insantiated. It could be in your App.config or an XML file or whatever else is convenient. Read this list during start-up and use it to populate a Dictionary to use as a look-up table. For the key, you could use the AssemblyQualifiedName of the base, or perhaps the corresponding Type instance. For the value, you should probably consider getting the ConstructorInfo for the child type.
A better way to load the default types is to provide an add method that stores the type in a hash table. This decouples the dependency container from the registration logic.
You may choose later to change the registration code to read the types from some file or something.
This question already has answers here:
When do you use reflection? Patterns/anti-patterns
(17 answers)
Closed 9 years ago.
So I tried searching SO hoping someone had a good explanation of this, with no luck.
I asked another friend of mine a different question (which I've now forgotten) and his answer was simply "reflection" before he signed off.
I am still very new to the C# world, having been an amateur VB.net programmer (also JavaScript, ActionScript, and C), and am trying as hard as I can to grasp these advanced concepts.
There's lots of philosophical answers -- "application looking at itself" -- but they don't provide any practical hints on what is actually going on or how it is used within that context.
So, what is reflection, why is it important, and why/how do I use it?
Reflection provides the ability to determine things and execute code at runtime.
You don't have to use it if you don't want to, but it is extremely handy for dynamic behavior.
For example:
a) You can use reflection to configure your application by loading an external configuration file and starting services based on it. Your application wont have to know in advance about the classes that implement those services, as long as they conform to a specific interface or API.
b) Using reflection you can generate classes and code on the fly, which simplifies certain programming tasks since the programmer does not have to explicitly create all the needed code.
c) Reflection is also invaluable for programs that work by examining code. An example of that would be an IDE or a UI designer.
d) Reflection helps you reduce boilerplate code.
e) Reflection is handy for defining mini Domain Specific Languages (DSL) in your code.
(my defintion)
Reflection is the ability to write static code that executes code at run-time, that is normally determined at compile time.
For instance, I could call a class method to draw by compiling in that command eg:
pen.DrawLine()
or With reflection, I can first see if my object has a method called "drawline" and if so, call it. (Note this isn't the actual C# Reflection syntax)
if(pen.Methods.Contains("DrawLine"))
{
pen.InvokeMethod("DrawLine"))
}
I'm no reflection master, but I used reflection for a plug-in architecture.
With reflection I can load a .NET assembly (a dll in this case) at run time, find out all the types that are in the .NET Assembly, see if any of those types implement a specific interface, and if so, instantiate the class, to which I invoke the interface methods.
I know that use-case is a bit technical, but essentially reflection allows me to load plug-ins dynamically (ie at run-time), and lets me make type-safe calls to it.
The most common use of reflection is an extension of what used to be called RTTI (run-time type information) and was primarily the domain of C++ programmers.
Reflection is a side-effect of the way .net is built and that Microsoft elected to expose the libraries they used to create Visual Studio and the .net run-time to developers outside of Microsoft.
Most of the reflection library focuses on type discovery and creation that can be invoked at run-time. This allows for some very powerful self-referential code. Take the following example at the heart of our configuration management system (some bits deleted for clarity):
public static IMyCompanySetting UnwrapSetting(XmlNode settingNode)
{
string typeName = settingNode.Attributes["type"].Value;
string typeAssembly;
if(settingNode.Attributes["assembly"] != null)
{
typeAssembly = settingNode.Attributes["assembly"].Value;
}
Type settingType = null;
Assembly settingAssembly = null;
try
{
// Create an object based on the type and assembly properties stored in the XML
try
{
settingAssembly = Assembly.Load(typeAssembly);
if (settingAssembly == null)
{
return null;
}
}
catch (Exception outerEx)
{
try
{
settingType = GetOrphanType(typeName);
}
catch (Exception innerEx)
{
throw new Exception("Failed to create object " + typeName + " :: " + innerEx.ToString(), outerEx);
}
}
// We will try in order:
// 1. Get the type from the named assembly.
// 2. Get the type using its fully-qualified name.
// 3. Do a deep search for the most basic name of the class.
if (settingType == null && settingAssembly != null) settingType = settingAssembly.GetType(typeName);
if (settingType == null) settingType = Type.GetType(typeName);
if (settingType == null) settingType = GetOrphanType(typeName);
if (settingType == null) throw new System.Exception(
String.Format("Unable to load definition for type {0} using loosest possible binding.", typeName));
}
catch (Exception ex)
{
throw new CometConfigurationException(
String.Format("Could not create object of type {0} from assembly {1}", typeName, typeAssembly), ex);
}
bool settingIsCreated = false;
IMyCompanySetting theSetting = null;
// If the class has a constructor that accepts a single parameter that is an XML node,
// call that constructor.
foreach (ConstructorInfo ctor in settingType.GetConstructors())
{
ParameterInfo[] parameters = ctor.GetParameters();
if (parameters.Length == 1)
{
if (parameters[0].ParameterType == typeof(XmlNode))
{
object[] theParams = { settingNode };
try
{
theSetting = (IMyCompanySetting)ctor.Invoke(theParams);
settingIsCreated = true;
}
catch (System.Exception ex)
{
// If there is a pre-existing constructor that accepts an XML node
// with a different schema from the one provided here, it will fail
// and we'll go to the default constructor.
UtilitiesAndConstants.ReportExceptionToCommonLog(ex);
settingIsCreated = false;
}
}
}
}
This code allows us to create a limitless number of classes that implement IMyCompanySetting and serialize and deserialize themselves using XML. Then, given a chunk of XML that is the output of object serialization, the system can turn it back into an object, even if the object itself is from a library that the serialization library doesn't have staticly linked.
There are 3 things that reflect does here that would be impossible without it:
Load an assembly at run-time based on its name.
Load an object from an assembly at run-time, based on its name.
Call an object constructor based on signature for an object of a class that is not known at compile time.
Say you have two alternate implementations of an interface. You want to allow the user to pick one or the other, via a simple text config file.
With reflection, you can simply read the name of the class whose implementation you want to use from the config file (as a string), and instantiate an instance of that class.
Reflection lets you dig into an assembly and use it, no matter that you don't have it referenced later.
Consider a plug-ins system, in which the host doesn't know about the plug-ins it will hold; with Reflection (and the correct architecture), you can construct a simple solution achieving this.
Consider another scenario in which you must to call the method on an object given a string, Reflection gives you the approach to achieve this as well.
There are many other usages but i hope these two, open your apetite to this excellent feature of CLR
It's sometimes useful to be able to read properties or invoke methods of a class without knowing what properties or methods a class has at design time. The way to accomplish this is with reflection. As demonstrated by the code below, you can get a list of all properties on a class and retrieve their values without knowing anything about it at compile time. Or you can get a method by name, even if you don't know the name of the method at compile time, and invoke it via reflection. This would allow you, for example, to create a scripting language that operates on objects defined in another user-supplied DLL. (Of course you can also enumerate all methods in a class or retrieve a specific property by name, but these cases are not demonstrated in the code below.)
class Program
{
static void Main(string[] args)
{
UserDefinedClass udc = new UserDefinedClass();
udc.UserProperty = "This is the property value";
ClassTracer ct = new ClassTracer(udc);
ct.TraceProperties();
ct.CallMethod("UserFunction", "parameter 1 value");
}
}
class ClassTracer
{
object target;
public ClassTracer(object target)
{
this.target = target;
}
public void TraceProperties()
{
// Get a list of all properties implemented by the class
System.Reflection.PropertyInfo[] pis = target.GetType().GetProperties();
foreach (System.Reflection.PropertyInfo pi in pis)
{
Console.WriteLine("{0}: {1}", pi.Name, pi.GetValue(target, null));
}
}
public void CallMethod(string MethodName, string arg1)
{
System.Reflection.MethodInfo mi = target.GetType().GetMethod(MethodName);
if (mi != null)
{
mi.Invoke(target, new object[] { arg1 });
}
}
}
class UserDefinedClass
{
private string userPropertyValue;
public string UserProperty
{
get
{
return userPropertyValue;
}
set
{
userPropertyValue = value;
}
}
public void UserFunction(string parameter)
{
Console.WriteLine("{0} - {1}", userPropertyValue, parameter);
}
}
Reflection is using the code to examine the code itself. For example, instead of calling foo.DoBar() you could call:
foo.GetType().GetMethod("DoBar").Invoke(foo,null);
That seems like a round-about method of getting to the same destination, but it can also be used to do some black magic that might break the rules, like calling private methods on framework classes, for example. It can also be used to actually generate code and output new binaries, and a whole slew of things that are extremely useful to a small group of people.
For more information, check out the MSDN section on Reflection.
There are many cases in which the application should not assume much about itself and should look at runtime to see what it actually is. This is where reflection comes into the show. For example, ASP.NET makes no assumption about the membership provider you use except that it inherits the appropriate class. It uses reflection to lookup the class at runtime and instantiate it. This gives out a great deal of extensibility due to decoupling and decreasing dependencies between classes.
This is, of course, only a single use case for reflection. There could be many other cases where it might be very useful.
Andrew Troelsen, author of Pro C# 2008 and the .NET 3.5 Platform, defines reflection this way:
In the .NET universe, reflection is the process of runtime type discovery.
I'm not sure I could give you an accurate explanation of what that means, but I can tell you how I've used it.
I can put a user-defined attribute on an assembly (dll). Using reflection at run-time, I can inspect all of the assemblies in a certain directory location to see if they have this attribute defined. This can clue my application on how to use the assembly, say as a plug-in.
I've also used reflection to load and save application settings.
For what it's worth, unless you're using reflection, I'm not sure what it has to do with your GUI throwing exceptions.
About the only thing I know about C#
reflection is that it is annoying as
hell because all my GUI apps like to
throw incredibly annoying, pointless
"Exception has been thrown by the
target of an invocation" exceptions at
Application.Run(new frmMain());,
instead of stopping where the real
problem happened (as shown in the
innerException).
Your statement makes me believe you have few if any try/catch blocks anywhere in your application such that every exception is percolating back to the top of the call stack. If you are using Visual Studio 2005/2008 in debug mode, go into the Debug menu and select the Exceptions... menu option. Inside the Exceptions dialog, check the checkboxes under the Thrown column. Now, when you run your application and an exception is thrown, the debugger will break where the exception is thrown.
Let's say you have some business entities which all come derive from a base class called Entity. Let's also say that you need/want all the derived classes to be cloneable. You can implement a method "Clone" (interface ICloneable) on the base class which would loop through all the properties of the current class (although it is implemented at the Entity class) and copy them to the cloned object. This is a case where Reflection can really help. Because you can't know the name and the count of the properties at the base class. And you don't want to implement the method in all derived classes. However you might want to make the method virtual.
Other people have answered for
what is reflection, why is it important
So I will be answering following questions only.
How do I use it?
Through following namespaces
System.Reflection
System.Reflection.Emit
Why do I use it?
To invoke/inspect assembly types, members, properties
When you look at a product like Reflector, being able to inspect code structure is more than practical enough.
If you run fast and furious, maybe you're inheriting from an object and need access to a private field. You don't have source, but thats ok you have Reflection. (hacky I know)
A more legitimate use I've seen is to use reflection in implementing C# generics where I want to do some operation on the generic type that isn't otherwise available. The only operations available on a generic type are those made available with a generic constraint (ie, if you constrain the generic type to implement IFoo, you can use IFoo methods on instances of that class). Some operations though just aren't available- for instance I was taking a generic class that was supposed to have a particular non-default constructor. I couldn't constrain the generic method to only accept generic type parameters with that constructor, but at least I could try and use that constructor when implementing the generic via reflection.
I use reflection sparingly but it occasionally comes in real handy.
I have used reflection to implement a custom data bindings system.
For example, with my bindings API I can write the following:
Binding b = new Binding(textBox, "Text", myObject, "Text", BindingMode.Bidirectional);
Any changes to the text in the textBox object are detected by the Binding object (which attaches to the TextChanged event) and passed into the myObject.Text property. Changes to myObject.Text are detected (by its TextChanged event) and passed into the textBox.Text member.
I implemented this system using reflection. The Binding constructor is declared as:
Binding(object, string, object, string, BindingMode)
The system therefore works with any object (with one important proviso).
I inspect the first object and find the member corresponding to the named member in the first string (textBox and "Text", ie. does textBox have a member called "Text"). Repeat with the second object and string.
Proviso: for objects to be used in this scheme they must implement the informal requirement that any bindable property must have a corresponding PropertyNameChanged event. Happily, pretty much all the .Net UI components follow this convention.
I then inspect the object for the requisite PropertyNameChanged events, add event handlers to them, and everything is set.
NB. I implemented this in .Net 1.0, so it predates Microsoft's bindings implementation - which I have not yet got round to investigating.
Practical Application
Use reflection for aligning Data with objects, as in a data mapping situation. For example, you can map a database column to an object's property. If you were to write an Object Relational Mapper, you would need some way to get from a configuration setting (i.e. DatabaseColumnName maps to Class.MemberName) to the objects to which it referring.
Reflection is so named because it allows ones code to take a look at itself just like looking in a mirror.
As previously mentioned reflection may be used to create new instances using a class name. Serialization is also powered by reflection. In this case the code examines all the serializable fields and serializes those recursively until the entire graph has been consumed and its byte form written.
Reflection allows one to escape static typing at compile time by discovering types, methods, fields etc at runtime. Many dynamic languages on the JVM (not sure about CLR but id imagine the same is true) use reflection to dispatch methods.
In terms of a practical use for reflection we have used it to allow our customers to provide their own localisation.
With our applications we provide a local resource database that the client can work through providing language translation for all strings, menu items, dialog controls...etc. With this client translated database in place we then use reflection on application launch and iterate through all our controls and replace default language strings with the client supplied translated strings.
There are many uses for reflection that have already been detailed here but another use might be to log the state of an object including its private members for use in debugging.
Can you post some sample code which shows how you are performing reflection? Do you have the PDB files in the same location as the assembly on which you are using the reflection API's?
If so, then in Visual studio go to the Debug menu -->Exceptions and check the check box "Common Language runtime thrown". Run your application in debug mode. Hopefully the debugger should break at the point in your reflected assembly at which the real exception is being thrown.