The POCO property is implemented by a backing field. Now (Reason to become obvious) let’s suppose the backing field is in a base class B. Both subclasses C1 and C2 expose some property on that backing field. If there’re 33 C1 instances and 44 C2 instances, then we have 77 of this backing field in memory.
* value — probably nothing fancy — a bool if the DProp should be bool
* key — a combination of the actual class (Button in this case) + the value’s type + the DProp name + …
For a Button instance in memory, if there are 80 DProps, then the hash table in the base class has, logically, 80 key/value pairs.
For a Label instance in memory, if there are 70 DProps, then the hash table in the base class has, logically, 70 key/value pairs.
Given 22 Buttons and 33 Labels on a screen, we have 55 hash tables. Logically, we can safely assume one hashtable per DependencyObject.
Without going any further, let’s step back and ask “Is this design enough to implement basic POCO property?” Basically setter/getters. I would say yes.
In reality we achieve memory efficiency because the hash tables are sparse. Out of the 80 DProps in the 22 Buttons, most of the 1760 values are defaults. All the default values are “removed” from the hash tables. http://stackoverflow.com/questions/7137291/how-does-the-wpf-dependency-property-design-save-memory-consumption and
http://stackoverflow.com/questions/9463216/how-dependency-property-holds-value have concise explanations.
Now, in this design the getter/setter have power features when used in conjunction with the “Hollywood registry” — Each of the 80 DProps in a Button is registered with the “Hollywood”. Therefore when the getter/setter runs, the Hollywood intervenes. Most important power feature is change notification. Overall, this Hollywood is still a mystery to me.