More on WPF attached properties

The more I look into the property support in WPF the more I think was correct in calling out that it is nothing more than a type-safe way of having extensible properties for beans. This is like the DynaBean in apache commons beanutils for non-class defined properties (but borrowing from others) and standard bean properties. Since you want change notification and other features in your properties, the DependencyProperty mechansims help you define properties that have nice bean setters/getters in your class while attached properties help you define a property in any class, and use it a class that implements DependencyProperty. Let's see how to do this differently.

Suppose you define the interface:

   public class DependencyObject {
      public Properties getProperties() { return ... }

      public void setValue(String key, Object value) { 
          getProperties().setProperty(key, value); 
      }
      public Object getValue(String key) {
          return getProperties().getProperty(key);
      }
   }

   public class MyObject extends DependencyObject {
       public int getX() { 
          return (Integer)getValue("X");
       }
       public void setX(int value) {
          setValue("X", value");
       }
   }

Then you could always do things such as:

   MyObject bean = new MyObject();
   bean.setX(10);
   bean.getProperties().setProperty("newProperty", "blah");

which sets 2 properties one defined using standard bean setters and getters and the other dynamically through a very simple property mechanism. One could define the "property" in another class:

    public class AnotherClass {
      public static final String BlahProperty = "blah";
    }

then follow through with:

    bean.getProperties().setProperty(AnotherClass.BlahProperty, "hah");

which essentially defines the pattern of attached properties in WPF. The differences are that the properties are define with more type information than just a property name based on a string and the properties definitions themselves are defined statically like in AnotherClass to minimize the memory footprint. In addition, the DepedencyObject class has some static machinery built that allows external classes to access that properties object a bit smarter than what we have done.

In WPF, the big advantage is that the static properties definition is more robust as mentioned above. It has type information, the type that owns the definition, some metadata about default values some more information about what parts of the object does it affect, for example, does the property affect layout processes.

Can this help in databinding? It could be a yes. The reason is that it is important to give objects hints about when to fire events, what type of binding to create, or just generally, provide "configuration" information to any object to make the binding smarter about how it should work...much like providing hint information. However, in data binding, the object you want to bind to may not have derived itself from DependencyObject so there is no automatic mechanism to attached new properties to it. So it seems like it is a no, if you don't derive from the right class, it makes it harder to extend any object with any property.