Understanding Reflection, Part 1
Subject:   Yes, but Why?
Date:   2003-10-16 08:06:42
From:   perlmunger
I have read a lot about reflection and understand what it gives me, but I haven't really found myself in a position to need to discover things about an object at run-time in contrast to knowing them at compile-time. I'm not saying there isn't a reason for it--I just don't know what the reason(s) would be. What are some real-world uses of reflection (besides simple use of the typeof operator)?


Full Threads Oldest First

Showing messages 1 through 2 of 2.

  • Yes, but Why?
    2004-07-14 09:49:59  andcal [View]

    There may be instances where you need to run several methods from the same assembly. For instance, when a user changes his/her password, th3e proposed new password would need to be checked against each one of the company's password rules.
    You could have the password change application use reflection to dynamically find all methods of the business rule assembly which contains the password rules (Each password rule is represented by one method). Then the change password app can call each of those methods, passing the (password) string, and checking for a return of boolean true.
    If you ever need to add a new password rule, you would only need to modify the password rule assembly, adding the appropriate business rule method. The calling application would still dynamically find each method, including the new one you added, and run each of them.
    Since you are changing less of the code, this can reduce the amount of testing needed before deploying the updated version.
  • Yes, but Why?
    2003-10-16 08:08:08  perlmunger [View]

    Nevermind. Didn't see that someone else just posted almost the same question.