If you want people to use your extension methods…

… you need to make them discoverable. That means temporarily abandoning your solution-structure-based namespaces and placing them directly in the namespace of the class you are extending so it comes up in intellisense immediately. Even if it’s from a totally different library, or System.* itself.

namespace YourCompany.Common.Extensions {    // don't expect anyone to find this here    public static class LinqExtensions { ... }}namespace System.Linq // can't miss it!{    public static class LinqExtensions { ... }}

If you’re using ReSharper you can also hit Alt+Enter and add the following so it won’t trigger code inspection warnings:

// ReSharper disable CheckNamespacenamespace System.Linq// ReSharper restore CheckNamespace{    public static class LinqExtensions { ... }}

Here’s a code snippet showing a little habit of mine — something I do to all my domain and application services:

public interface IPortfolioRepository : IDomainService{    ...}public interface IPortfolioAdministrationService : IApplicationService{    ...}

What’s in these base interfaces? Nothing. They are just labels, used to help make make object roles explicit:

public interface IApplicationService {}public interface IDomainService {}

Why is this a good idea?

1. It helps makes implicit concepts — e.g. this is a domain service — explicit.
2. It grants you freedom with your class names, without having to suffix everything with Service or Event.
3. It lets you do cool stuff like write integration tests to check all your application services are registered correctly.

They’re not only limited to services, by the way. Use them for aggregate roots, entities, value types, and other types of objects:

public interface IPortfolio : IAggregateRoot{    ...}public interface IPortfolio : IEntity{    ...}public class Money : IValueType{    ...}public class BookAddedToPortfolio : IDomainEvent{    ...}

Udi Dahan’s Making Roles Explicit is a must-see presentation on this subject, if you haven’t already seen it. In fact, this example is only a small subset of what you can do with this technique.

If you’re a new developer, one term you’ll hear used a lot is state. I remember I struggled with the idea at first, so I thought I’d write a brief introduction to the concept of state, and how it is applied to a few design and testing principles.

What is state?

Let’s use me as an example. Here are three facts that describe my current state:

• My name is Richard.
• I’m 23 years old.
• I just ate some of my flatmate’s pancakes for lunch (wohoo!).
• I’m in a pretty good mood.

In code, you might represent this as:

public class Person{    public string Name;    public int Age;    public Activity CurrentActivity;    public bool IsHungry;    public MoodType Mood;}

These fields comprise my state. Some are unlikely to change (my name, for instance) while others are much more volatile (I will be hungry again in a few hours).

So you can see state changes over time. For example, my state right now is totally different than my state after 40 hours of nonstop travel from London from New Zealand — I arrived tired, and pretty frazzled. Both these states are different again than when I’m asleep.

State can be recorded, persisted (e.g. saved to a Person table in a RDBMS) and tracked over time. Usually, though, we’re only interested in the current state.

So state is just data, right?

Well… yes and no. When persisted, state becomes data, and in an object, state represents the data portion. Remember object-oriented programming combines behaviour (methods) with data (state).

But at a higher level, state represents the overall picture of an object right now, how it will behave, and what range of actions are available. A good example of this is the State Pattern from the GoF book. In their example, a TCP network connection has different states: established, closed, or listening for an incoming connection. These states are each encapsulated into an object, assigned to a field and the TCPConnection delegates behaviour to the current state:

So you can see in examples like this, state is more than just data — it affects behaviour too.

Unit testing state vs unit testing behaviour

This is something you might hear in the context of TDD and BDD. In short, testing on state means looking at an object’s visible state after something happened, and checking that all the values are correct.

bankingService.Transfer(chequeAccount, savingsAccount, 100.0);// State-based assertionsAssert.AreEqual(0.0, cheque.Balance);Assert.AreEqual(100.0, savings.Balance);

In comparison, testing on behaviour means using mocks to verify the expected methods are called.

bankingService.Transfer(chequeAccount, savingsAccount, 100.0);// Behaviour-based assertionschequeAccount.AssertWasCalled(account => account.Withdraw(100.0));savingsAccount.AssertWasCalled(account => account.Deposit(100.0));

Generally behaviour-based testing is preferred, because:

1. Focusing on behavioural seams (methods on interfaces) results in looser coupling, because the internal implementation of objects should change more often than the interfaces between them.
2. The internal state of an object is private, and you shouldn’t be looking at it anyway — the basis of the Tell Don’t Ask principle.

Stateless services

An object’s state effects its behaviour. For example, when I eat, I feel full. If I eat too much, I feel sick — I can’t continue eating over and over.

Services, on the other hand, should be stateless. Imagine a dice-based random number generator. Every dice roll is a clean start — it should not retain any memory between rolls. To simplify usage and scale better, all service calls should be like this.

Another simpler example of unwanted state is services with methods like Initialize(), Start(), Connect(), Open() etc that must be called before other methods. Users of this service need to take responsibility for calling it and thus managing the lifecycle of the service — an unreasonable burden that introduces unnecessary coupling.

Explicit state transitions

One newer technique in domain-driven design is recognizing important state transitions, and making them explicit through the use of events. A simple example of this could be when your bank account balance goes below zero, its state becomes overdrawn:

public class Account{    public void Withdraw(Decimal amount)    {        balance -= amount;        if (balance < 0)            DomainEvents.Raise(new AccountBecameOverdrawn(this));    }}

This is an important state change — part of the business’s ubiquitous language that might have further implications down the line e.g. incurring overdraft fees. Udi Dahan writes a lot on this topic — it is a big help in decoupling your domain model, and is is the basis for event-sourcing CQRS.

So hopefully that starts to gives you an idea of what state is all about — more than just data!

Null Object pattern for a WPF ComboBox’s deselected value

Last week, I encountered a problem doing some fiddly UI behaviour in a Prism/MVVM app. I wanted something like this:

FX curve:

I wanted a ComboBox where you can choose one of the available options, or none of them. Null, deselected, whatever.

Unfortunately for me, WPF doesn’t support binding null values in ComboBoxes, ListBoxes or ListViews. Now this is a pretty common problem, and a quick google reveals a few solutions available to this problem:

• Add an “IsNull” property to your models
• Wrap the ComboBox in an adapter that provides null support
• Create an attached property that clears the selected item when the user hits DEL

However, if like us, your domain model is all nicely decoupled through interfaces, the easiest way to get null values into a ComboBox is with the null object pattern. (And thankfully for me doesn’t require any knowledge of WPF control internals to implement).

Here’s what my null object looked like:

public class NullCurve : IFxCurve, IEquatable<NullCurve>{    public string Name { get { return ""; } }    public void DoStuff() {} // Has no implementation    // Note the equality overload. Null objects are value types -- they    // have no identity, and are all equal.    public bool Equals(NullCurve other)    {        return other != null;    }    public override bool Equals(object obj)    {        return Equals(obj as NullCurve);    }    public override int GetHashCode() { return -1; }}

To use it, you simply pop a null object at the start of your list. And check whether it was selected on submit:

public class FxCurveSelectionViewModel : ViewModelBase{    public ObserableCollection<IFxCurve> AvailableCurves { get; private set; }    public IFxCurve SelectedCurve { get; set; }    public FxCurveSelectionViewModel(ICurveRepository curves)    {        AvailableCurves = new ObservableCollection<IFxCurve>();        AvailableCurves.Add(new NullCurve());        AvailableCurves.AddRange(curves.GetAllCurves());    }    public void Submit()    {        if (SelectedCurve.Equals(new NullCurve()))            // nothing was selected    }}

XAML binding is standard; no need to change anything because we handle it all in the view model. Which arguably is not the most DRY solution long-term, but sufficient until I learn more about WPF internals to do it elegantly with XAML.

When writing software there are a number of problems which start off simple — simple enough to knock up your own solution — but usually blossom into something much more complex over time.

Logging is one such problem. It starts off with a simple three-liner function using File.AppendText(), but as requirements grow, you need to add things like timestamps, thread-safety, differentiating errors vs informational messages, archiving, and logging to a database. Before you know it, your three-liner logging function has blossomed into a very poor implementation of log4net.

I’ve seen this sort of thing happen often with teams that haven’t had much exposure to open-source library development, but get excited at the opportunity to create some reusable components of their own (which is why you should always be immediately suspicious of internal ‘common’ libraries and ‘custom frameworks’).

The trick is to recognize when the burden of maintaining a home-brew solution no longer makes sense versus integrating an existing library.

In business this is known as build versus buy, and there are of course some situations when it is smarter to build. For example if there are no third-party libraries available in your problem space, or they are immature, or no longer maintained, or they are encumbered with costs/licensing restrictions. Or sometimes you may prefer a unique implementation that actually is better. But all these should be at least recognized and considered before making a decision.

A simple example of this came up last week, when I was developing a command-line tool for running common user scenarios against our system for benchmarking purposes.

One of the intended goals was that we be able to script it into a post-build process, so command-line options were required for verbose logging, repeating scenarios over and over, whether or not to ignore errors, and of course which scenario to run.

Now, like logging, command-line options are not exactly rocket-science. This sort of code is perfectly acceptable:

if (args.Contains("/v")){    // verbose mode enabled}

However this can easily spiral into something far more complex with positional parameters, optional arguments, validation, options that cancel each other, defaults, long options, not to mention supporting both slashes and hyphens.

For this benchmark tool I didn’t even bother writing my own — having used getopt for C and Boost Program Options for C++ in a previous life, I set off immediately to find something similar for .NET.

I ended up selecting NDesk Options, an open-source library for parsing command-line options. It comes from the unix/mono side of .NET where bash still rules supreme, so you know it’s got to be good. And it is. With lambda-based callbacks for each option, and support for just about every command-line switch style known to man, I had the following knocked up in a few minutes:

All that help text is generated automatically for minimal effort. Cool!

As you may know, I’ve recently started at a new position here in London. Last week I was pair programming all day, every day, with a couple of the other developers, learning the ins and outs of the system. It reminded me of an important tip for beginners: good pair programming requires both driver and observer to maintain focus between making a decision and implementing that change.

< p>

Renaming a class or a method can be done throughout your code in a fraction of a second with built-in IDE shortcuts. But something like promoting a static method to an injected service (still a pretty common refactoring) can easily take a couple of minutes to actually do. In this time, there’s not much going on for the observer, except listening to the sound of typing. And waiting. And trying not to get bored.

(If you’re unlucky enough to be paired with me, I’ll probably be completely distracted and playing with all the things on your desk by this point.)

Now, I am no stranger to pair programming, and have used it many times before for small tasks. But this is the first time I’ve ever done it solidly for several days at a time. This past week has been a real eye-opener for me in terms of quickly making code changes; although I have been using ReSharper for a while now, I have a new found appreciation for its keyboard shortcuts, and people who can use them effectively. Which sadly doesn’t include me yet.

Using your mouse to navigate code and poke through menus is just too slow, and it really shows when you are refactoring code in front of someone else. A good driver minimises the lag between agreeing on a change and effecting it with lighting-fast typing skills. So unplug your mouse, and go learn your tools’ keyboard shortcuts!

Announcement: in just over a fortnight I’ll be packing my bags to go chase the kiwi dream – I’m moving to London!

Provoke has been a wonderful home for the past two years, and I thank all my workmates and clients who made my time there so special. Working here has really been an unforgettable experience, and I hope to take a little bit of that magic onto future jobs and organisations.

So far, my immediate plan for the next few months involves .NET architecture/development work in London, probably on contract basis so I can fit in some travel around Europe between projects. I’m also keen to check out the various developer conferences like QCon and Oredev. But first, I need to start packing!