Sorry for that. I needed a catchy title ;).
Well, now that I’m a WPF Disciple I should probably blog more about WPF. What’s interesting though, is despite the fact that I’m now working on a WPF project, most of the coding I’ve been doing lately has not been UI related. So, not much to blog about WPF.
Well, over lunch today my mind was wandering over the stuff I have worked on lately. Among them was the IoC container I’ve been tooling about with. One of the things I did with the container was to extend the functionality through extension methods. Worked great, but occasionally your extensions needed new state information that didn’t exist on the object. Well now, this ties back to WPF after all.
See, there’s this concept in WPF that directly addresses this. It’s called an "attached property". An attached property is a property associated with an object instance, but the backing store isn’t the object itself. This is accomplished through DependencyObject and DependencyProperty classes. A DependencyObject has GetValue() and SetValue() methods that take a DependencyProperty as a parameter, and get/set values for that dependency property through some magical backing store that’s not actually part of the object (basically the storage is some giant HashMap). An attached property is a special type of DependencyProperty that allows you to attach values to any DependencyObject, not just the object on which the DependencyProperty is defined.
So, by turning my ObjectContainer into a DependencyObject, I can allow extension methods to maintain their own state information on the container they are extending! Such a simple concept, and yet it didn’t dawn on me to do this in my initial implementations. I rolled all of the necessary plumbing to track associated external state information by hand, and did it every time I needed new state information in a new extension method. What a waste of time and effort! 🙂
I think I’m starting to fall in love all over again with DependencyObjects. I’ve avoided using them anywhere but at the UI layer. I thought it was wrong to bring in all of this baggage at the data/domain layer. After all, INotifyPropertyChanged gave me everything I need at that level, and Don Box agreed with me. Well, now I think Don and I were wrong.
You see, even at the domain layer, it’s not that unusual to need an "extension mechanism". Some way for a known domain object to be extended with more features under certain circumstances. We’ve all rolled specialized mechanisms for allowing this in the past. However, with a DependencyObject this functionality is baked in, using a mechanism that’s well supported by the rest of the framework. I used to think that dependency properties were too much of a PITA to deal with unless you absolutely had to… but I think I’m changing my mind. The flexibility and functionality you gain by deriving from DependencyObject is probably enough to outweigh the development cost, especially if you use a good set of snippets.
I’ve done a lot of programming in dynamic languages. The ability to add functions and data to an existing object always proved invaluable in those languages. Of course, the lack of compile time checks on all of that made maintaining those code bases a bit of a PITA. It’s kind of exciting to realize now that I have most of the capability to do this but in a statically checked at compile time nature.