When assembling any assembly in .NET (ASP.NET, Windows Forms, the command line, class library, etc.), the assembly also creates a series of "metadata definition tables" that store information about methods, fields, and types that correspond to types , fields and methods that you wrote in your code.
Classes in the .NET System.Reflection namespace allow you to list and interact with these tables, providing an βobject modelβ for querying and accessing elements in these tables.
One common use of Reflection is to provide extensibility (plugins) for your application. For example, Reflection allows you to dynamically load an assembly from a file path, request its types for a specific useful type (for example, an interface that your application can call), and then actually call a method on this external assembly.
Custom attributes also go hand in hand with reflection. For example, the NUnit unit testing framework allows you to specify a test class and test methods by adding the [Test] {TestFixture] attributes to your own code.
However, then the NUnit test runner must use Reflection to load your assembly, search for all instances of methods that have the test attribute, and then actually call your test.
This greatly simplifies it, however it gives you a good practical example of where Reflection is needed.
Reflection, of course, is powerful, but, nevertheless, it allows you to completely ignore the fundamental concept of access modifiers (encapsulation) in object-oriented programming.
For example, you can easily use it to get a list of private methods in a class and actually call them. For this reason, you need to think carefully about how and where you use it to avoid circumventing encapsulation and a very tight connection (of bad) code.