Inside WPF’s DependencyObject & DependencyProperty
January 19, 2009
Posted by on
This is one of my older post, which I would like to copy here. WPF programmers (& also WF programmers) would have heard the names of these 2 classes. It’s quite easy to take these 2 classes for granted (unless you are into custom control or custom activities creation). The lines below provide some motivation from WPF perspective & also clearly differentiates between both classes. I found them useful, so thought of copying it here. Hope you find it too🙂 .
If you have spent some time drilling into WPF you are bound to run into 2 classes – DependencyObject & DependencyProperty. They two together provide the base for underlying Property System of WPF. It’s well documented that DependencyObject is nothing but a glorified hashtable, but the same holds true for DependencyProperty too.
For e.g. have a look at following code:
public class Person : DependencyObject //CTRL + K + X -> Insert snippet shortcut for inserting Dependency Property
public static readonly DependencyProperty NameProperty = DependencyProperty.Register("Name", typeof (string), typeof (Person));
public string Name
return (string) GetValue(NameProperty);
The function that caught me in the above code was DependencyProperty.Register – What the heck is that doing? On probing further I discovered that DependencyProperty maintains a Hashtable internally called PropertyFromName. PropertyFromName is where all the dependency properties of WPF are stored. A property is uniquely identified on basis of it’s name & owner. For instance if you try to register another property in the above code (may in a different class) with the same name & owner type (that is Person) you will get an ArgumentException. DependencyProperty also stores other attributes like default value of the property (e.g. every Person can have a default name called ‘Unknown’).
E.g. Person.NameProperty = DependencyProperty.Register(“Name”, typeof(string), typeof(Person), new PropertyMetadata(“Unknown”));
Let’s focus on DependencyObject now. DependencyObject itself internally maintains an hashtable. DependencyObject contains 2 important methods called GetValue & SetValue which are used to retrive values from the internal hashtable. The hashtable comes into play when you try to modify the default value of DependencyProperty. For e.g. the default name of every person is let’s say ‘Unknown’ & you are setting it to your name. So the value you are giving goes & sits inside the DependencyObject’s hashtable. Important thing to note here is in many cases the value may not be explicitly set by you but the value may be derived from surroundings. E.g. let’s say the creator of class Button has set it’s default background to white & you haven’t explicitly set the background but when you run the application you see that background color is black. Now this may be due to Operating System’s theme you have selected. Hence many developers refer to DependencyObject as a value engine.
So the question that comes to mind is why such complexity was required in first place? Answer is quite simple. If this properties weren’t dependency properties then would have been normal .NET properties allocated per instance. Dependency properties are created per type & can be customized if required (like per instance). So if your screen has 20 buttons you storage space for properties occupied is as good as for one button. Of course things can change if all the properties of buttons are modified for all 20 buttons which is a very rare scenario.
How about calling this a sparse storage design pattern😀 ?