private override

8Dec/087

static reflection – INotifyPropertyChanged

I'm not going to delve into the definition of static reflection here, but you'll see how it's implemented, and how I found it can help me with implementing INotifyPropertyChanged.

Now, I've never been a fan of INotifyPropertyChanged myself, mostly because it feels wet (read: not DRY).  I'm working on a WPF app at the moment, and have come to realize, if I embrace INotifyPropertyChanged, I get to take full advantage of the excellent WPF databinding story.

Here is what a normal use of INotifyPropertyChanged looks like:

    public class Person : INotifyPropertyChanged
    {
        private string _firstName;
        private string _lastName;

        public event PropertyChangedEventHandler PropertyChanged;

        public string FirstName
        {
            get { return _firstName; }
            set
            {
                if (_firstName != value)
                {
                    _firstName = value;
                    FirePropertyChanged("FirstName");
                }
            }
        }

        public string LastName
        {
            get { return _lastName; }
            set
            {
                if (_lastName != value)
                {
                    _lastName = value;
                    FirePropertyChanged("LastName");
                }
            }
        }

        private void FirePropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

Here is what the static reflection use of INotifyPropertyChanged looks like:

    public class PersonStaticReflection : NotifyPropertyChanged
    {
        private string _firstName;
        private string _lastName;

        public string FirstName
        {
            get { return _firstName; }
            set { SetProperty(()=> FirstName, ()=> _firstName, value); }
        }

        public string LastName
        {
            get { return _lastName; }
            set
            {
                SetProperty( () => LastName, () => _lastName, value, () =>
                   {
                       // do something useful here
                   });
            }
        }
    }

Doesn't that just feel DRYer?  It does to me!

There are several important pieces to note:

  • Inheriting from NotifyPropertyChanged, this is the class that holds the SetProperty method, and hides the static reflection magic.
  • We're calling SetProperty with three arguments in the FirstName property
    • first: a LINQ Expression pointing to the property we're changing
    • second: a LINQ Expression pointing to the field to backing the property
    • third: the new, incoming value
  • We're calling SetProperty with a fourth argument in the LastName property
    • fourth: an action that will get executed only if the values were different
  • The SetProperty method, is going to look at the current value of the field, and the incoming value.  If the two are different, it will assign the new value to the field, and then fire the NotifyPropertyChanged event, with the name of the property given via the first argument.  I ended up pulling this into its own class so I could use it as the layer supertype in my View Model layer. Here is the implementation:

    public class NotifyPropertyChanged : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        protected void SetProperty < T>( Expression < Func> propExpr, Expression> fieldExpr, T value )
        {
            SetProperty(propExpr, fieldExpr, value, ()=> { });
        }

        protected void SetProperty < T>( Expression < Func> propExpr, Expression < Func < T>> fieldExpr, T value, Action doIfChanged )
        {
            var prop = (PropertyInfo)((MemberExpression)propExpr.Body).Member;
            var field = (FieldInfo)((MemberExpression)fieldExpr.Body).Member;

            var currVal = prop.GetValue( this, null );

            if( currVal == null && value == null )
                return;
            if( currVal == null || !currVal.Equals( value ) )
            {
                field.SetValue( this, value );
                doIfChanged();

                if( PropertyChanged != null )
                    PropertyChanged( this, new PropertyChangedEventArgs( prop.Name ) );
            }
        }
    }

Questions/comments/likes/dislikes? Let me know.

Comments (7) Trackbacks (4)
  1. I was always annoyed by implementing INotifyPropertyChanged. I’ll definitely being using this in the future

  2. It seems like you want a decent (i.e. not C preprocessor) macro system. On .Net the best language for this is probably Nemerle or Boo. You can just write (in Nemerle, I don’t remember Boo syntax)

    [NotifiableProperty]
    public string _firstName;

    and it will be converted to

    public string FirstName
    {
    get { return _firstName; }
    set
    {
    if (_firstName != value)
    {
    _firstName = value;
    FirePropertyChanged(“FirstName”);
    }
    }
    }

    at compile time, no run time overhead! See here: http://nemerle.org/Macros

  3. It seems like you really want a decent macro system. In .Net that means, at the moment, either Nemerle or Boo.

    I don’t remember Boo syntax, but in Nemerle you can just write

    [Accessor(flags = WantSetter)]
    mutable _someField : int;

    and it will be converted at compile time to

    mutable _someField : int;
    public SomeField : int {
    get { some_field }
    set { some_field = value }
    }

    Writing a macro which would insert FirePropertyChange calls as well is pretty easy.

  4. Sorry for the double comment

  5. Great work. Helped me very much.

  6. Err, what about the situation where you cannot really subclass from NotifyPropertyChanged because you’re already inheriting from something else? This whole approach hinges on inheritance which prevents it being used anywhere. At this point, I’d typically suggest a mixin, except that mixins cannot contain state (without a lot of pain), and you have an event whose value must be accessible.

    I think, for the time being, it makes sense to just use PostSharp for the INotifyPropertyChanged problem.


Leave a comment