Refactoring to Patterns: WPF Edition

To some it may appear that I have abandoned client side development for Azure. Nothing could be further from the truth. As I’ll tell anyone who will listen, I’m just like a kid who’s opened his presents on Christmas and found a new toy to play with. After playing with the new toy for a while, eventually I’ll remember my old favorite and start playing with it again. (The real fun comes of course when I start playing with both together). It’s not a Buzz Lightyear vs. Woody…it’s more like Megatron vs. Galvatron. Anyway, I had to come back to Megatron at some point or another. And a recent thread within the WPF Disciples mailing list gave me that impetus. I’ve recently realized how effective refactoring can be for getting working code out rapidly while still addressing maintainability. My experiments with refactoring resulted in a technique I like to call "context sensitive architecture."

A Practical Application

I’m not a huge fan of contrived applications, but sometimes we do what we must. This won’t be one of those times. Let’s say you have an application that could provide a rich view of your digital life and how that digital life is connected. Let’s say for now the application could show contacts and bookmarks. Finally, lets say that the application wants to allow the user to add and edit contacts and bookmarks. How do you enable these scenarios? One way would be to create a CreateContactControl, an EditContactControl, a CreateBookmarkControl, and an EditBookmarkControl. I guess we want to allow the user to View their contacts and bookmarks. Now we have to add a ViewContactControl and a ViewBookmarkControl. What happens when we add RSS Feeds and Podcasts to the mix? Now we have to create six more controls and integrate them into the system. What’s worse is that the main app has to know about each and every control in order to display them at the appropriate time. Of course we could use plug-in model to alleviate some of this pressure, but this could end up generalizing your application to the point where it is little more than a shell. There’s nothing necessarily wrong with that, but I still think there’s a compromise between the two extremes. Sometimes that compromise isn’t very obvious. Hence, we use refactoring and iterative development to discover the compromise.

The First Iteration

The first iteration of a project should be used to implement what is called a "vertical slice" or two. This will allow us to realize the benefits of Agile development with the first delivery. Getting working software into the customer’s hands quickly provides a compelling argument in favor of Agile development. I would actually recommend that you start with a minimal core team (2-3 members) for the first few iterations, this will enable you to minimize the overhead due to collaboration as the team takes its first steps into a new domain. It will also allow a few patterns to emerge before ramping up the velocity. Because you’re targeting a smaller amount of functionality for the iteration, you might want to do a shorter iteration. I think two weeks should be adequate.

Before we go any further, let’s try to visualize this app with a pair of its scenarios: "Add a Contact" and "Add a Bookmark". The "Add a Contact" story is very simple: "As a user of the application, I want to be able to enter information about a contact for later retrieval and viewing: his or her first and last name, and email address." Likewise the "Add a Bookmark" story is equally simple: "As a user of the application, I want to be able to store information about a bookmark for later retrieval and viewing: the URL, and title of the bookmark."

Based on these stories, we have identified two entities for our domain model: Bookmark and Contact. Here is the Bookmark:

   1:  using System;

   2:   

   3:  namespace Flow.Model

   4:  {

   5:      public class Bookmark

   6:      {

   7:          public Uri Address { get; set; }

   8:          public String Title { get; set; }

   9:      }

  10:  }

The Bookmark is very simple, consisting of a Uri and a Title. We will probably identify more information that would be interesting to capture for a bookmark in a later iteration. For now, we want to get working code into the hands of our stakeholders as quickly as possible. Our second object of interest is the contact:

   1:  using System;

   2:   

   3:  namespace Flow.Model

   4:  {

   5:      public class Contact

   6:      {

   7:          public String FirstName { get; set; }

   8:          public String LastName { get; set; }

   9:          public String EmailAddress { get; set; }

  10:      }

  11:  }

Let’s make a pair of controls for creating new bookmarks and contacts. Following the WPF developer – designer workflow, I will make the first pass on the UI simplistic and straightforward (relying on my designer to beautify it later).

After a few minutes in Blend, followed by some cleanup in Cider, I came up with a rather straightforward, minimalistic UI with the primary elements defined for optional elaboration by my designer:

Now that I have a way to create contacts and bookmarks. I should allow the user to view them. That’s easy enough. Let’s make a ListBox that shows the collection of contacts and another pair of controls that are read only. Rather than worrying about persistence at this point we’ll just store the information in memory.

So What Next?

We’ve delivered some basic functionality to our customers. More importantly, we have started the first path in our journey together. I will be placing the code on Codeplex. In addition I will be posting a screencast of me writing this code (once I figure how to get Camtasia to co-operate with me). This is something I’ve wanted to do for quite a while now. I just couldn’t find a project that I was compelling enough that would be able to grow from a very simple solution to a very interesting WPF application. I will reveal more about it over the upcoming weeks; in the process documenting the evolution what I feel is a very interesting application. Tune in for more info.