Fun and games with reflection

[andrewducker]

I originally wrote this for the c# discussion forum at work, and if you don't use c# you'll be wanting to press the page-down button any second now...

Let's say you want to check whether a control is set to ReadOnly. The simple way is to say :
if(control.ReadOnly) {}

But, I hear you say, not all controls have a ReadOnly property. In fact, only TextBoxBase (and its descendants) have a ReadOnly property. Which is entirely true, most of the time. Not at all true, however, if the control has been subclassed and a ReadOnly property has been added. In which case what would be handy is a way of checking whether a control has a boolean ReadOnly property, and if it does returning it.

Which is where reflection comes in:

private PropertyType GetProperty(Object myObject, string
propertyName)
{
      Type typeInfo = myObject.GetType();
      PropertyInfo propertyInfo = typeInfo.GetProperty(propertyName);
      if (propertyInfo != null)
      {
            object property = propertyInfo.GetValue(myObject, null);
            if (property is PropertyType)
                  return (PropertyType)property;
      }
      return default(PropertyType);
}

which may look complex, but all it's doing is getting the Type Information for your object, checking to see if it has a property with the correct name and checking to see if it matches the correct return type. If it does then you get the information back, if not you get a default value (null for objects, zero for numbers, false for booleans).

You can call it to retrieve the Text property like so:
string title = CheckProperty(myForm, "Text");
or as a replacement for the original if statement at the top:
if(CheckProperty(control, "ReadOnly")) {}

And I wouldn't advise you to use it all the time (there being an overhead for reflection, and it being less clear than straightforward property checking), but it can be very handy on occasion.

Comments

[call-waiting.livejournal.com]

Well...

...it's not only inadvisable because of the overhead, it's also inadvisable in the sense that using introspection in this way is, in essence, hacking around a bit of design that's missing somewhere further up the chain, and in almost any case the 'right' thing to do is to go back up and fix that.

I'm not quite sure what you mean by 'the control has been subclassed and a ReadOnly property added': d'you mean some other control not descendid from TextBoxBase? Or some subclass of TextBoxBase adding its own property of that name (note: I know next to nothing about C#, so I wouldn't know whether or not that's even possible ;) In the former case, it's only a naming convention that saves the day, otherwise there'd be no guarantee that such a method would have that name, or indeed that a method with such a name would have the same functionality.

This doesn't hold true (well, not exactly) if there happens to be some formal definition of the method names to which the class conforms, ie. an interface (does C# have interfaces?), and if that were the case, then that interface would actually provide the mechanism for the 'correct' solution to the design problem.

Now, I feel compelled to go read about C# ;)

[andrewducker]

The problem is that it's not always very easy to retrofit design. I _could_ create an IReadOnly interface (yes, C# has interfaces - a class can inherit from one base class and implement a many interfaces as you'd like) and make sure that all the classes that implement a ReadOnly boolean also note that they implement IReadOnly. However, if I did that I'd also have to subclass TextBox and RichTextBox (the two subclasses of TextBoxBase that you actually use) to implement it as well, and then go through a few hundred files in the system replacing all instances of TextBox with MyTextBox (or whatever). Which would be a vast amount of effort.

Instead, I've basically implemented a basic form of Duck Typing, which _is_ a hack - but one that gets my system working in 8 lines of code, all in once place, and doesn't depend on people remembering to use my special subclass of TextBox rather than the built in class.

I've not found many places where I'd do things like this, but I think it's a perfectly valid way to do things when you don't have access to the base classes to edit them (else I'd add IReadOnly to the base class, obviously).

[call-waiting.livejournal.com]

Ah yes, the old imported design problem problem. My first reflexive (if you'll pardon the pun...) reaction to that one is to suggest an interface, and for those objects that won't implement the interface directly, a proxy object class which queried the actual object in question; of course this isn't a good fit for a whole bunch of reasons, the most pressing being first that it's likely the majority of the objects you're looking at are in fact going to be descended from the imported base class, neccessitating proxies for damn near everything, and second that since you're in a GUI app, you're probably going to be wanting to deal with issues like this in a handler that's passed a reference to the GUI object in question, as descended from the base class, and so mapping from that to an object implementing the right interface is non-trivial.

This is one of the sorts of problem that AOP intended to solve, and I note there are a decent number of C# aspect-oriented programming tools, though I'll bet none of them solve the IDPP without the source code of the imported components, which I'm sure will be unavailable given that it's an MS thing.

In short, I still maintain it's the wrong answer to the right question, but the right answer to wrong question; and since the wrong question is the only one with an answer... as you were, soldier; dismissed.

[andrewducker]

In some ways, the mapping object would be something that queried to make sure that the correct interface was being followed, probably using code not vastly dissimilar to my method above. And for an interface containing just one property, I've effectively got everything I need.

I was inspired to take this approach from reading an introduction to Duck Typing in C# on a website somewhere, and this seemed to be _a_ fit. I agree that it's not aesthetically pleasing though.

[andrewducker]

Aha! Original article was here:
http://www.codeproject.com/cs/library/nduck.asp