The timing seems right to demonstrate a pattern for testing asynchronous processing. This follows up on Steve's assertion: Don't make assumptions, write the test.

For purposes of demonstration our user story will be: As a program I want to output a message after an event is raised. So let us start by writing a test. Our story implies an event reader and a writer. So let us use the runtime execution provided by test runner and make that the reader. The writer will be some other simple class.

namespace Test.AsynchronousProcessing
{
    [TestFixture]
    public class EventReader
    {
        [Test]
        public void CreateInstance()
        {
            Assert.IsInstanceOfType(typeof (EventWriter), new EventWriter());
        }
    }
}

If you run the tests for EventReader, CreateInstance will fail of course. So let us do the minimal necessary to make the test pass: create EventWriter class. By the way...by convention the code listings show only relevant material.

    public class EventWriter
    {
    }

One of the most ubiquitous patterns in life is the template. It enables us to generalize behavior - thus ignoring or postponing complexity.

This ability to generalize behavior - deferring derivative details - turns out to be extremely useful in agile software development. It encourages mock-object practices. It encourages simplest possible solutions. It encourages test-driven development. And most importantly it embraces change.

What is the template-method pattern? A good example is found in JUnit. TestCase.run() defines a generic process: 1) setup before running test; 2) run test; 3) tear down after running test. The complexity is provided by derivative TestCase types - but the process is same for every run.

public class TestCase {
  // details elided
  public void run() {
    setup();
    runTest();
    tearDown();
  }
  protected void runTest() {
  }
  protected void setUp() {
  }
  protected void tearDown() {
  }
}

Just mention design patterns in a development setting and you may incite riot. Some dispute their taxonomy - many dismiss their utility - while others unaware of the topic entirely. So with proper expectations set I have solicited the PerCS authors to write about the various patterns.

These posts will not be high-level; they will be real-life application of patterns. They will contrast patterned design with random design. But most of all they will contain freely distributed, well patterned code.

Creational Patterns

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

Structural Patterns

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

Behavioral Patterns

• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

I am right in the middle of Agile Software Development (highly recommended). Along the same lines I came across this introduction to dependency inversion principle. The author does well to contrast the dependency injection mechanism of various IOC containers.

Joel on Software has posted reflections on the programming equivalent of defensive driving. In Making Wrong Code Look Wrong, Joel posits that certain design and convention practices promote defensive programming and overall QE...while others send you to a bad place fast.

Most successful development methodologies advocate "same page" conventions. The notion is that any reasonable approach works - just as long as everyone consistently uses it. So on that basis (and others) the kind annotation convention that Joel puts forth is fine.

The morning started out with an interesting problem: I need a variable size array of value types (integers in that particular case) ArrayList would be the weapon of choice if you don't need highest performance, or just use int[] and write the array resizing code for the nth time. I didn't have the inclination for either solution so I resorted to an unusual solution - give the problem some thought. As a result, I found a few things that were news to me, and that I would like to share.

First, I wrote a little program to see check out the different assignment mechanisms:

This is a quick follow up to the Grid Computing column of a couple weeks ago.

As suspected, there is a product called videoclix (and probably others) that allows to create hotspots in a video where you can click into a streaming video and – of course – buy stuff. It supports everything Quicktime supports including DV, which means it works on low level formats. It is not a real-time solution though, which is not required for the content creation and marketing customers for whom this product seems to be developed. They say they add about 20K of metadata to each minute of video, which seems to be minimal for the use I envision.