Property Event Pattern

Published Thu, Jun 17 2004 23:59 | coad

Introduction
Since the advent of .NET, one of my most frequent and useful patterns is using an event to notify change in state. Applying this pattern has reduced overall code, improved reliability, and made maintenance and expansion easier.

Why? The Context
Without events, spaghetti code occurs real quickly when one method changes state that other code is dependant on without notifying that the change is made. This is one of the most frequent causes of coding errors (bugs) in mid-to-large applications that I have seen. Events go a long way in solve this issue.

This should be obvious with public properties that can be changed externally, but must be acted upon by the owner. Such as the Text property on a label, when changed, the label must be redrawn.

Common Example
This is used extensively on Windows Forms components. Almost every property has an associated change event. TextChanged for the Text property, EnableChanged for the Enabled property and so on.

Internally Critical
This pattern becomes more subtle but critical with internal members. In larger applications, for clarity, I wrap most all class variables in properties with change events. If the class is designed to be inherited, this becomes all the more important as you can not rely on derived classes to notify your code when they change state.

The Solution

  • Subscribe to Events
    Code that depends on a class' state can subscribe to the appropriate change event to receive notification of when that state changes to take appropriate action.

  • Event Triggers
    The "Event Triggers" allow easy triggering of the event and allow derived classes the option of first notification (before the event occurs).

  • Internal Access Through Properties
    Even internal members should access the variable through the property to ensure that notification occurs. In other words, members should not access the class variable directly, only through the property.

#region Public Events
public event EventHandler DevicePortChanged;
#endregion

#region Property Variables
private int m_DevicePort;
#endregion

#region Public Properties
public int DevicePort
{
  get {return m_DevicePort;}
  set
  {
    int saved = m_DevicePort;
    m_DevicePort = value;
    if (saved != value) OnDevicePortChanged(EventArgs.Empty);
  }
}
#endregion

#region Event Triggers
protected virtual void OnDevicePortChanged(EventArgs e)
{ if (DevicePortChanged != null) DevicePortChanged(this, e); }
#endregion

References

Filed under:

Comments

# coad said on June 18, 2004 1:20 AM:

jaybez [MS] talks about trying to reduce the amount of code to implement this pattern.
Properties as objects: http://weblogs.asp.net/jaybaz_ms/archive/2004/06/14/155452.aspx
Properties with events: another attempt: http://blogs.msdn.com/jaybaz_ms/archive/2004/06/16/157682.aspx

# coad said on June 18, 2004 9:29 AM:

I like the concept, but don't you think you should implement an event accessor instead of having a public event? It would offer a level of abstraction for doing something when an event is subscribed/unsubscribed. e.g.

private EventHandler m_devicePortChanged;
public event EventHandler DevicePortChanged
{
add{ m_devicePortChanged += value;}
remove{ devicePortChanged -= value;}
}

# coad said on June 18, 2004 10:56 AM:

Jeffrey: If you write an event with the field syntax, the compiler merely generates 'add' and 'remove' for you. There's a good reason to let it: your implementation has a bug. You didn't lock. Let the compiler do it for you, and you don't have to worry about it.

http://www.jaggersoft.com/csharp_standard/17.7.1.htm

# coad said on June 25, 2004 2:46 PM:

A benefit would be to log the action of subscribing or unsubscribing to the event.

# coad said on March 29, 2005 2:13 AM:

Shouldn't there be a lock in OnDevicePortChanged?