Update #2: JP called to tell me that this really isn’t a decorator pattern. It’s actually the adapter pattern. Like he said in his training course, identifying patterns in the wild is hard to do and takes a lot of practice. Looks like I need a lot more practice. He also asked about a factory class to create these items, and I figured that it would be nice if I put the one I had created up here too.
I’m working on some stuff for the EViL project again. After my training last week, I’ve been looking at the work I do a little differently and this project is no different. For me, the great thing about working on EViL is that it allows me to explore the depths of the System.Reflection namespace. In the last couple of days I’ve found some interesting things.
I was working on some additions to allow for validation against private fields in classes and I noticed that the PropertyInfo and FieldInfo classes didn’t implement a common interface or base class that had the GetValue method on it. In the end, I needed to be able to get all of the PropertyInfo and FieldInfo classes into one collection so that I could iterate through the values in search of matches to perform validation on. Here’s how I went about it. Now, it may not be the best way. I may not have named this right. Regardless, this solved the problem for me and I figured I’d share it.
In the end what I did was wrap the PropertyInfo and FieldInfo classes in a SmartPropertyInfo and SmartFieldInfo
Decorator Adapter classes. By creating the wrapper, and it’s correlating interface, I was able to make both PropertyInfo and FieldInfo data look and behave the same. EViL is now completely agnostic to the classes that are provided by reflection.
Update: After an email from David Woods I decided to implement one more level of refactoring to clean this up even more.
public class SmartPropertyInfo : ISmartMethodInfo