Web application development can get tricky. Not only are we, as developers, charged with constructing brilliant websites that address every requirement each project entails, we also have to be concerned with the things not explicitly listed in our requirements document - things like how do we secure it? How do we know it's working at peak performance? How can we make sure people are entering in the data they're supposed to? On top of all that, if we're doing business website development, be sure to stay abreast of current application development technologies, the best ways to improve search engine optimization and last but not least, be sure to address brand experience strategy in everything you do.
See? Tricky. Fortunately, developers are weird. We like the challenges each web application development project presents. Really. We're weird.
Now despite this apparent quirkiness, in any software project we're working on, if there's something someone's built before that can help speed the development process along, we're likely going to use it. Design patterns represent tried and true ways to accomplish certain tasks in code - they're structures that solve problems common to many different project types. Confronted by a massive project with a tight deadline? Spot a process that can be handled by a design pattern? Sign me up! Design patterns to the rescue.
One of the most common design patterns which has been implemented time and time again is the Observer pattern, which is basically a structure that allows you to setup one or more entities (the observers) that react to changes in another entity (the subject). Not an uncommon scenario, right? Think RSS news readers that display news items as they are posted on the remote server. The observer pattern has solid grounding in real-world scenarios too; think of the iconic "hot doughnuts now" sign from your doughnut shop of choice – they light it up, people come running. Ok, maybe not the best of examples, as people still have the choice to grab a doughnut or not, but hey, it’s a vice, what can I say?
Traditionally the Observer pattern is implemented by using a set of objects derived from a common set of interfaces, namely the IObserver interface for objects we want to be notified of changes in another object, and the ISubject interface for the object we want to be watched. Basically, the ISubject interface defines a set of public methods to manage observer signup and notifications as outlined in code segment 1:
Segment 1
interface ISubject
{
public List<IObserver> RegisteredObservers { get; set; }
public Boolean state { get; set; }
public void RegisterObserver(IObserver observer)
{
RegisteredObservers.Add(observer);
}
public void RemoveObserver(IObserver observer)
{
RegisteredObservers.Remove(observer);
}
public void UpdateRegisteredObservers()
{
foreach(IObserver observer in RegisteredObservers)
{
observer.Update(state)
}
}
So a set of methods to add and remove any objects derived from the IObserver interface to an internal list of IObserver objects which is used in the Update method to notify the observers of any change to the ISubject object, in this case a simple Boolean field called state (ugh, brutally obvious, I realize, but prudent..) . The observer objects implement their own interface outlined in segment 2:
Segment 2
interface IObserver
{
public void Update(Boolean state)
{
//update status to reflect change in subject
}
}
And as expected, IObserver contains just one method to update itself to reflect any change in the subject object.
Not so difficult, right? A handy mechanism to handle distributed subscriber-based notifications for a number of different circumstances; if you haven’t found yourself in a situation where you needed to distribute multiple updates based off one event, trust me you will, and you’ll be happy you know about your friendly neighborhood Observer Pattern
Now while you are more than welcome to implement the Observer pattern using this traditional dual-interface manner, in .NET, there really is a better way. (You knew I was getting to it at some point, didn’t you?) Because the Observer pattern is so heavily entrenched in object-oriented development these days, and since the maintenance of registered observers can get pretty tricky pretty quickly in a traditional Observer pattern implementation, Microsoft went ahead and built its own short-hand version directly into the C# language from the very first version (yup, C# 1.0, don’t see that much anymore do you?) through the simple use of events and delegates. Microsoft uses it so much in their own internal coding, they even went so far as to rename it the Event Pattern (Oooo, Aaahh..)
OK, so here’s how it’s done: we’re going to build a subject class to expose an event whenever it changes internally, then we’re going to define a delegate to handle that event, which we’ll use to link all our observers to the subject– and we’ll transmit the subject’s change in state through a custom EventArgs class. Now, if that sounds like a lot, don’t freak out just yet, if you’ve ever wired up code to an event in .net, you’re already well acquainted with how events and delegates work through the standard signature of an event handler – think of a button click event handler like the one outlined in code segment 3.
Segment 3
public void Button1_Click(Object sender, EventArgs e)
{
//button event code goes here
}
See that EventArgs parameter? That’s how .Net passes parameter values to event processors. So the cornerstone of implementing our own .net observer is by overriding the default System.EventArgs class with our own version to hold the information we need to pass to our observers from our subject class. Sound like a plan? Let’s get started.
Code Segment 4 lists a custom event class which contains two readonly properties, oldvalue and newvalue – we’ll use this class to notify all our observer objects whenever there’s a change in our Subject’s values.
Segment 4
public class SubectChangedEventArgs : EventArgs
{
//these values will hold values our observers want to know about
private readonly int oldvalue;
private readonly int newvalue;
//constructor that sets old & new values
public SubectChangedEventArgs(int oldval, int newval)
{
oldvalue = oldval;
newvalue = newval;
}
//readonly properties to return Subject values
public int OldValue { get { return oldvalue; } }
public int NewValue { get { return newvalue; } }
}
Ok, so now that we have a custom EventArgs class, we need to declare the event handler which our observers will mimic to receive subject change events – our delegate:
Segment 5
public delegate void SubjectChangedEventHandler(Object sender, SubectChangedEventArgs e);
The SubjectChangedEvenHandler defines a method signature which all our observers will implement to receive notifications from our subject; two parameters are defined – an object and an instance of our SubjectChangedEventArgs. When declared as a method in one of our observer classes, the object parameter will be a reference to the Subject object the Observer is watching, and changes to its values will be held in our readonly SubjectChangedEventArgs class; code segment 6 lists a typical observer object implementation.
Segment 6
public class SubjectObserver
{
//int to list change in value
int change;
//subject change even handler to match our delegate and use our custome EventArgs class
public void SubjectChange(Object sender, SubectChangedEventArgs e)
{
change = e.NewValue - e.OldValue;
}
//constructor that requires a subject to observe
public SubjectObserver(Subject s)
{
//Register our delegate-based method to the subject instance
//This is how we link our observers to the subject
s.SubjectChanged += this.SubjectChange;
}
}
So, the SubjectObserver class has one method that matches our delegate defined to handle any changes in the subject, and we wire up the observer to the subject by linking our delegate-based SubjectChange method to our subject’s ‘SubjectChanged’ event as an event handler. Nice, huh? .Net baked-in goodness. The final piece of our puzzle is the Subject class itself. The Subject class has two responsibilities – to expose an event for changes to its internal value (which we’ll use to hook all our observers to as event handlers), and to ensure it raises this event any time a change to its internal value occurs. Code Segment 7 lists how our Subject class is structured.
Segment 7
public class Subject
{
//private int to hold the current subject's value
private int subjectValue = 0;
//public property to set the subject value,
//the set method is where we capture the value change and
//notify all the registered observers of the change
public int SubjectValue
{
get { return subjectValue; }
set
{
// new eventargs class to pass the current subjectValue and the new value
SubjectChangedEventArgs e = new SubjectChangedEventArgs(subjectValue, value);
//update the subjectValue
subjectValue = value;
//Signal all the observers
OnSubjectChanged(e);
}
}
//declare the event using our SubjectChangedEventHandler delegate
// to handle changes to the subjectValue
//we'll also use this to attach our list of delegate-based observers to.
public event SubjectChangedEventHandler SubjectChanged;
//method to trigger our subject change event
//Note: events can only be triggered from within their respective types,
// thus we marked the scope as virtual protected to allow the method
//to be over-ridden while still being able to raise the default event
virtual protected void OnSubjectChanged(SubjectChangedEventArgs e)
{
SubjectChanged(this, e);
}
}
So there we have it, a public property with its setter calling a protected function to raise its own event to notify all our registered eventhandler observers. Any time the subject changes, the SubjectChanged event gets raised, and all our observers can react to the new value enclosed in our own custom SubjectChangedEventArgs class.
Now, admittedly that seems like a lot of work compared to the traditional ‘I only need two interfaces’ Observer pattern implementation, but the payoff is in the use of the pattern, as shown in Segment 8 which outlines the process of using the classes we detailed previously to gain our .Net Observer pattern sweetness.
Segment 8
Subject subj = new Subject();
SubjectObserver observer = new SubjectObserver(subj);
SubjectObserver anotherObserver = new SubjectObserver(subj);
subj.SubjectValue = 33;
//both observer and anotherObserver both update immediately
int observerValue = observer.Change;
int anotherObserverValue = anotherObserver.Change;
Ok, now seriously, how freakin’ cool is that? No messy ‘I’m an observer, add me to the list of registered observers’ calls, no ‘ok, I’ve changed, let’s loop through the list of registered observers and let them know’ routines, just wicked fast event-based programming. And did I mention the wicked-fast-ness of this .net Observer implementation? Oh yeah.
Again this is a .Net-specific implementation of a widely recognized and utilized design pattern of modern object-oriented programming, the Observer Pattern. Microsoft uses this pattern extensively in their own class structure for the .Net framework – so much so, they’ve come to call it the Event Pattern.
Oooh, Aaah…
Regardless, if you haven’t had the need to implement a similar pattern in your own coding projects, you probably will run into it sometime in the future, and when you do, you are now armed with the powerful and pervasive .Net Event Pattern.
Brand integration in programming was a big topic for the advertisers here. There was even a company on the floor pitching a software solution that inserts banners into video called SeamBI for seamless branding integration.
When running an direct response campaign, there are a lot of variables at play. Choosing the right combination can be the difference between a successful campaign and a campaign cut short due to poor performance. To set yourself up for success, conisder these factors when planning your direct response strategy:
Powered by Compendium