Pet Peeve #726

Alright, so this is a weird thing to get me blogging again, but it really annoys me.

In English, the -ing suffix is reserved for verbs. 

Simple as that, really. If you want to create a verb out of a noun, you can add -ing. Appropriately it’s called verbing.

It really jars when I see a noun with the -ing suffix (words like “thing” don’t count, obviously).

This means that there is a no such thing as a refactoring.

“To refactor” is the verb. Therefore, “refactoring’ is something you do. You can do a single refactor. You cannot do a single refactoring. You can do multiple refactors. You cannot do multiple refactorings.

Also… Advice is like sheep – it’s the same whether singular or plural. In AOP, you do not apply ‘advices’, you apply ‘advice’ even if you happen to be applying many of them.

</pedantry>

Put boolean arguments last

Whenever I see a method call like this:

Enum.TryParse(stringRepresentationOfEnum, true, out enumValue);

I wonder what the `true` parameter really represents. In this instance, because I know that method from past experience, I know that this is the ignoreCase parameter.

However, what if this is a totally different method that you’ve never seen before:

service.DoOperation(DateTime.Now, true, false, false, true, currentValue, userName);

This is a particularly sadistic method. But let’s assume that this is the necessary signature of the method. Sadly, it is very unclear what the boolean values do that are being passed in here. What options do we have for adding clarity, assuming we can’t alter the interface?

Firstly, we could pass in some named variables for each of the boolean values:

bool includeHeader = true;
bool checkSecurity = false;
bool validateDate = false;
bool fireCompletionEvent = true;
service.DoOperation(DateTime.Now, includeHeader, checkSecurity, validateDate, fireCompletionEvent, currentValue, userName);

This is already much better, but it is untidily verbose. While we have much more clarity as to what is being passed into the method, it comes with a bit of noise in having to declare the parameters. This feels especially redundant because the variable names will likely be the same as the formal parameter names. As of C# 4.0, we need not do this. Instead, we can use named parameters:

service.DoOperation(DateTime.Now, includeHeader: true, checkSecurity: false, validateDate: false, fireCompletionEvent: false, currentValue, userName);

Sadly, this doesn’t quite work as hoped- the last two parameters are `positional` parameters and cannot appear after named parameters. This means that we must introduce some redundancy:

service.DoOperation(DateTime.Now, includeHeader: true, checkSecurity: false, validateDate: false, fireCompletionEvent: false, currentValue: currentValue, userName: userName);

This is why I would advocate putting boolean values last in the formal parameter list:

service.DoOperation(DateTime.Now, currentValue, userName, includeHeader: true, checkSecurity: false, validateDate: false, fireCompletionEvent: false);

This is much clearer, but it does require you to design your method signatures with this in mind.

I, Interface

Let’s take a simple interface and see what we can do with it.

public interface ITask()
{
    void Do();
}

This is pretty much as simple as it gets- a single void method which is parameterless. It models a task inasmuch as you can ‘do’ a task. That’s all this interface is fussed with: providing clients the ability to do something.

Given this very simple interface, we can exercise all sorts of patterns on it and furnish it with even more power through flexibility.

Null

One of the most useful things we can do is have clients behave correctly when given a null ITask reference. Ordinarily, the client would either have to test manually that the task is not a null reference, or it would throw a NullReferenceException. Through diligently substituting an instance of a special ITask implementation, instead of null, we can ensure that we have no more NullReferenceExceptions:

public TaskNull : ITask
{
    public void Do()
    {

    }
}

That’s all there is to it. Perhaps it could be a bit more intelligent (logging that a null task was attempted to be done, for example), but as long as we are sure to return an instance of this class rather than the null reference each time it is applicable, clients will not throw.

Compose

Next up, we can compose many tasks into this:

public class TaskComposite : ITask
{
    public TaskComposite(params ITask[] tasks)
    {
        this.composedTasks = new List<ITask>();
        if(tasks != null)
        {
            foreach(var task in tasks)
            {
                AddTask(task);
            }
        }
    }

    public void Do()
    {
        foreach(var task in this.composedTasks)
        {
            task.Do();
        }
    }

    public void AddTask(ITask task)
    {
         if(task != null)
         {
             this.composedTasks.Add(task);
         }
    }

    private List<ITask> composedTasks;
}

So, we can group a load of tasks together to be executed serially.  TaskComposite implements the ITask interface, so it can be passed into any constructor or method that requires an ITask and will execute all of its composed tasks when the client asks to Do the task. There’s also nothing to stop us from passing a TaskComposite to a TaskComposite, thereby creating a complex graph of tasks. When executed, the behavior is deterministic: the tasks will be done in depth-first order.

Predicate

public TaskPredicated : ITask
{
    public TaskPredicated(Func<bool> predicate, ITask task)
    {
        if(predicate == null)
        {
            throw new ArgumentException("predicate");
        }

        if(task == null)
        {
            throw new ArgumentException("task");
        }

        this.taskShouldBeDone = predicate;
        this.decoratedTask = decoratedTask;
    }

    public Do()
    {
        if(this.taskShouldBeDone())
        {
            this.decoratedTask.Do();
        }
    }

    private readonly Func<bool> taskShouldBeDone;
    private readonly ITask decoratedTask;
}

By wrapping an ITask in this decorator, you can have the task done conditionally, depending on the outcome of an external predicate*. Again, notice that this class is an ITask. This ITask can even be passed to the TaskComposite as one of many tasks. Now we have the ability to treat many ITask implementations as if it were one ITask, where some may or may not be executed, depending on some contextual predicate.

Branch

By extrapolating the predicate example, we can also elect to execute something on the false branch of the if-statement:

public TaskBranched : ITask
{
    public TaskBranched(Func<bool> predicate, ITask trueTask, ITask falseTask)
    {
        if(predicate == null)
        {
            throw new ArgumentException("predicate");
        }

        if(trueTask == null)
        {
            throw new ArgumentException("trueTask");
        }

        if(falseTask == null)
        {
            throw new ArgumentException("falseTask");
        }
        this.taskShouldBeDone = predicate;
        this.trueTask = trueTask;
        this.falseTask = falseTak;
    }

    public Do()
    {
        if(this.taskShouldBeDone())
        {
            this.trueTask.Do();
        }
        else
        {
            this.falseTask.Do();
        }
    }

    private readonly Func<bool> taskShouldBeDone;
    private readonly ITask trueTask;
    private readonly ITask falseTask;
}

Interrupt

How about the scenario where you want to do task A unless some event occurs and you then want to do task B?

First of all, we’ll need to pass an event into the constructor of this TaskInterruptible, but .NET doesn’t let us do that, so let’s model it as a trivial interface.

public interface IInterrupt
{
    event Action Signal;
}

We will need a class to implement this in order to adapt some other event. Imagine, for example, registering for a mouse-click, key-press, network IO or NServiceBus message and then firing the Signal event in response. This keeps our TaskInterruptible free from code specifically to handle those events.

public class TaskInterruptible : ITask
{
    public TaskInterruptible(IInterrupt interrupt, ITask normalTask, ITask interruptTask)
    {
        if(interrupt == null)
        {
            throw new ArgumentException("interrupt");
        }
        if(normalTask == null)
        {
            throw new ArgumentException("normalTask");
        }
        if(interruptTask == null)
        {
            throw new ArgumentException("interruptTask");
        }
        this.interrupt = interrupt;
        this.normalTask = normalTask;
        this.interruptTask = interruptTask;
    }

    public void Do()
    {
        this.interrupt.Signal += DoInterruptTask;
        this.normalTask.Do();
    }

    private void DoInterruptTask()
    {
        this.interruptTask.Do();
    }
}

Hmm, it’s a great start, but I’m not wholly happy with this yet. There’s a large possibility that these two tasks – normal task and interrupt task – are mutually exclusive and should not be running concurrently. This introduces a new concept – that a task can be cancellable. Are all tasks necessarily cancellable? If so, then we can add a new method onto the ITask interface. However, in the interest of the interface segregation principle I’m going to say that not all tasks are cancellable – some might elect to be, some might not. This, then, gives us a new interface:

public interface ICancellable
{
    void Cancel();
}

Again, this interface is really nice and simple. Let’s provide another decorator around ITask that will cancel something before running the wrapped task:

public interface TaskCancel : ITask
{
    public TaskCancel(ICancellable objectToCancel, ITask taskToRun)
    {
        if(objectToCancel == null)
        {
            throw new ArgumentException("objectToCancel");
        }
        if(taskToRun == null)
        {
            throw new ArgumentException("taskToRun");
        }
        this.objectToCancel = objectToCancel;
        this.taskToRun = taskToRun;
    }

    public void Do()
    {
        this.objectToCancel.Cancel();
        this.taskToRun.Run();
    }

    private readonly ICancellable objectToCancel;
    private readonly ITask taskToRun;
}

While I’m not sold on the name of this implementation, I’m pretty happy that I can now cancel anything that needs to be, before running a task.  As long as it implements ICancellable, I can freely pass it in as the first argument. There’s nothing to stop me from passing the same task in as both parameters – effectively restarting a task!

Now, I can pass an instance of this class as the interrupt task above, providing it with the normal task as the ICancellable (given that it is cancellable, of course) and I can rest assured that the previous task will be cancelled before running the new task. Lovely.

Thread

Some tasks might take a long time to execute. Given that all sorts of things can now be happening when you execute an ITask, it may be important to run a task on a separate thread. For instance, if a composite task contains three different tasks, the first of which takes a minute to complete, the other two tasks are just going to wait until that task is complete because they are executed serially on the same thread.

public interface TaskThreaded : ITask
{
    public TaskThreaded(ITask task)
    {
        if(task == null)
        {
            throw new ArgumentException("task");
        }
        this.taskToThread = task;
        this.backgroundWorker = new BackgroundWorker();
        this.backgroundWorker.DoWork += (sender, eventArgs) => DoTask();
    }

    public void Do()
    {
         this.backgroundWorker.RunWorkerAsync();
    }

    private void DoTask()
    {
        this.taskToThread.Do();
    }

    private readonly ITask taskToThread;
    private readonly BackgroundWorker backgroundWorker;
}

Obviously, the usual threading caveats apply to this: if concurrent tasks use common, volatile, memory then this needs to be managed carefully.

However, if the tasks are totally independent like in our hypothetical example, the first, long-running, task can be wrapped in this TaskThreaded decorator before being added to the composite. When run, the call to Do() will last only as long as it takes to start the new thread, with any subsequent tasks then running in parallel.

It’s also not a stretch to imagine that these threaded tasks are also, in fact, cancellable…

public interface TaskAsync : ITask, ICancellable
{
    public TaskAsync(ITask task)
    {
        if(task == null)
        {
            throw new ArgumentException("task");
        }
        this.taskToThread = task;
        this.backgroundWorker = new BackgroundWorker();
        this.backgroundWorker.DoWork += (sender, eventArgs) => DoTask();
        this.backgroundWorker.WorkerSupportsCancellation = true;
    }

    public void Do()
    {
         this.backgroundWorker.RunWorkerAsync();
    }

    public void Cancel()
    {
        this.backgroundWorker.CancelAsync();
    }

    private void DoTask()
    {
        this.taskToThread.Do();
    }

    private readonly ITask taskToThread;
    private readonly BackgroundWorker backgroundWorker;
}

Now, this could be combined with the TaskCancel and the TaskInterruptible so that a long-running task can be run on a separate thread until some interrupting event occurs, at which point some other task occurs in its stead.

Yeah? And? So? What?

The point to all of this is that, with these infrastructural implementations in place, we can happily contrive whatever flow of tasks we require –  without changing any of the clients that use this interface. This is bold, italic and underlined for a very good reason – it’s that important. We can achieve a separation of concerns and maintain the single responsibility principle, both at the same time. We separate the concerns by allowing a florid object graph to grow around an interface, rather than foisting that behavior on clients. We maintain single responsibility because each of the component parts are very much focused – you will have a class that provides a predicate*, a class that implements an interrupt, a handful of classes that implement tasks.

By exercising the interface segregation principle, these interfaces can spring up a lot. That isn’t to say that, for every interface, all of these implementations should be in place – far from it – merely that there are plenty of occasions where one or two of these used in collaboration can move complexity out of clients that have no business knowing about it.

If applied even minimally, there will be a lot of (good, laudable) constructor injection going on here. However, by leaning heavily on your dependency injection framework (Unity, Castle Windsor, Spring.NET, etc.), there is only a bit of up-front effort in registering the implementations in the application’s entry point. You can even write unit tests that will exercise the DI configuration by ensuring you can resolve all of the composition roots. If the graph can’t be constructed at initialization time, then you can implement a factory that can manually construct the graph depending on any kind of context you require.

We’re living off SOLIDs, now!

*Note that, in this example, I’m using a Func<bool> delegate as a predicate because I have no context that I wish to pass – something that Predicate<TContext> requires. If you wish, you could even define an interface IPredicate with a single bool method – called ‘Test’ or some such – because interfaces are much more flexible than delegates.

Towards better unit testing organization…

I try to follow a test-first approach at all times. However, the way in which I organize my unit tests has evolved over the past five years or so.

Originally, I would follow the pattern espoused in unit testing tutorials:

[TestFixture]
public class CalculatorFixture
{
	[Test]
	public void CanAddTwoPositiveNumbers()
	{
		var calculator = new Calculator();
		int result = calculator.Add(13, 45);
		Assert.AreEqual(58, result);
	}

	[ExpectedException(typeof(OverflowException))]
	[Test]
	public void OverflowCausesException()
	{
		var calculator = new Calculator();
		calculator.Add(int.MaxValue, 1);
	}
}

This is pretty much as simple as it gets. However, it is time-consuming and does not promote reuse of repeated code. While we can move initialization into methods marked [SetUp] this will be run for every test in the fixture, which might not be suitable.

So, I factored things out into a proper Arrange, Act, Assert pattern. I forget where I picked this up from, but – as with many things – I spotted it, briefly evaluated it and decided to run with it.

[TestFixture]
public abstract class TestBase
{
	[SetUp]
	public void Init()
	{
		GivenThat();
		When();
	}

	protected virtual void GivenThat()
	{
	}

	protected abstract void When();
}

This is still fairly simple, but much more expressive. It allows me to specify my tests as follows:

[TestFixture]
public abstract class WhenUsingTheCalculator : TestBase
{
	protected abstract override void GivenThat()
	{
		base.GivenThat();
		this.calculator = new Calculator();
	}

	private Calculator calculator;
}

public abstract class WhenAddingTwoNumbers : WhenUsingTheCalculator
{
	protected override void When()
	{
		this.result = this.calculator.Add(X, Y);
	}

	protected abstract int X { get; }

	protected abstract int Y { get; }

	protected int result;
}

public class WhenAddingTwoPositiveNumbers : WhenAddingTwoNumbers
{
	protected override int X { get { return 13; } }

	protected override int Y { get { return 45; } }

	[Test]
	public void ItShouldReturnTheCorrectResult()
	{
		Assert.AreEqual(58, this.result);
	}
}

public class WhenAddingNumbersThatCauseOverflow : WhenAddingTwoNumbers
{
	protected override int X { get { return int.MaxValue; } }

	protected override int Y { get { return 1; } }

	[Test]
	public void ItShouldThrowAnOverflowException()
	{
	}
}

This style isn’t much of an improvement, to be entirely honest. Sure, it generates a nice output when a test fails (“WhenAddingNumbersThatCauseOverflow.ItShouldThrowAnOverflowException() failed”). Note that the latter test won’t work, though. More work is required to allow expected exceptions to be caught (hint: the exception is thrown in When() and the [Test] methods are run after this).

I persevered with an enhanced version of this for a while though, because the reuse seemed worth the pain of such a leaky abstraction. But, the fact that the reuse was through inheritance ended up causing a bit of a problem, because anyone who came to the tests after they were originally written were flummoxed by the complex, deep hierarchies. Sometimes this person was me…

I recently decided to go back to the drawing board to try to find something that would hit the following requirements:

  • Support the reuse of initialization code and assertions
  • Rely more on composition than inheritance for creating tests
  • Be really easy to understand for anyone seeing tests for the first time (tests are a reliable form of documentation)
The result is as follows:
Unit Testing domain

First, a quick explanation. A unit test has very simple behavior: Arrange() the preconditions, Act() on the target object, Assert() the postconditions. This is probably all a test runner will need to know about a unit test (if that, it could probably just ‘Run()‘ unit tests, but by splitting them into constituent parts, we could try/catch around only the Assert() looking for AssertionExceptions, for example).

Where data is concerned, a unit test is composed of many initializers, many assertions and one action. Notice that each of these components do not exclusively belong to a single unit test instance, but are shared among them, promoting reuse.

Implementing this model quickly showed how far you can stray from documentation in just a short while. I’m going to skip posting and explaining the implementation (but I’ll supply a link at some point with the code when I’m happy with the result). Instead, I’ll share the bit that really matters: how it looks to clients.

Under my CalculatorTests project I have one file called Initializers.cs (for all Calculator preconditions) one file called Assertions.cs (for all Calculator assertions) and then a file called CalculatorTests.cs which contains all of the unit tests pertaining to the Calculator class. Note that this is the only file that people need look in to discern the intent of the code.

Initializers:

public class CalculatorIsDefaultConstructed : IInitializer<ICalculator>
{
	public void Prepare(ref ICalculator target)
	{
		target = new Calculator();
	}
}

Assertions:

public class ResultShouldEqual : IAssertion<ICalculator, int>
{
	private int expectedValue;

	public ResultShouldEqual(int expectedValue)
	{
		this.expectedValue = expectedValue;
	}

	public void Verify(ICalculator target, int returnValue)
	{
		Assert.IsNotNull(target);
		Assert.AreEqual(this.expectedValue, returnValue);
	}
}

public class ExceptionThrown<TException> : IAssertion<Exception>
	where TException : Exception
{
	public void Verify(Exception exceptionThrown)
	{
		Assert.IsInstanceOf(typeof(TException), exceptionThrown);
	}
}

The unit tests now look like this:

public class CanAddTwoPositiveNumbers : UnitTest<ICalculator, int>
{
	public CanAddTwoPositiveNumbers()
	{
		GivenThat<CalculatorIsDefaultConstructed>();
		When(calculator => calculator.Add(13, 45));
		Then<ResultShouldEqual>(58);
	}
}

public class OverflowCausesException : UnitTest<ICalculator, int>
{
	public OverflowCausesException()
	{
		GivenThat<CalculatorIsDefaultConstructed>();
		When(calculator => calculator.Add(int.MaxValue, 1));
		ThenThrow<OverflowException>();
	}
}

So, each unit test has its Arrange, Act, Assert components clearly visible as well-named classes, but the implementation of each is hidden away elsewhere. It can be inferred what CalculatorIsDefaultConstructed does, so you don’t need to see its guts. The almost English-language specification of the test is quite nice, too. I’m going to add a fluent interface to the initialization and assertion registration, to include And(). This is now, for all intents and purposes, Behavior Driven Development (BDD)…

There are a couple of issues with this approach, still. Mainly, it is overkill for the example presented here. The initializers and assertions made aren’t complex enough to warrant their own classes and the readability of the intent isn’t sufficient reason to justify the extra fingerwork.

I’m about to write a non-trivial suite of unit tests using this organization and I will report back with my findings and – by then – some code. The implementation of UnitTest is integrated into NUnit so I can use its framework wherever required.

How do you organize your unit tests?

Do you really need an ORM?

An Object-Relational Mapping (ORM) is necessary only when you have 1) an object model, and 2) a need to persist this object model to a Relational Database Management System (RDBMS).

The latter may be a given, especially in web-based scenarios. However, the former is not always so clear-cut.

You have an object model if you have a collection of fully-fledged classes with both data and behavior.

Object Oriented Design (OOD) is predicated on the tight coupling between an object’s data and the methods that operate on that data. Without the associated behavior you are left with an anemic domain model. What you have is an object graph with relationships and data that map to the problem domain, but the fine-grained behavior is limited to getters and setters for the data.

A simple Blog class diagram; note the lack of object behavior

Often, the ‘business logic’ is extracted into a service layer which orchestrates the objects at a much more coarse-grained level.

The UML diagram shown is a very simple blog class diagram. Notice that there are objects, with names matching the nouns in the problem domain. However, there is no behavior on any of the objects. User is missing verbs like Login, CreateCategory and SubmitComment. Post is missing verbs like SaveDraft and Publish. Comment is missing verbs like Accept and Flag.

These are the fine-grained behaviors that will probably end up rolled into a service layer’s higher-level functionality. There is nothing wrong with this, providing that there is not an ORM sitting between this object graph and persistent storage (as opposed to just serializing the object graph).

As blogs are typically online, it is reasonable to assume that there would be an RDBMS used as the persistent storage. This covers one half of the prerequisites of using an ORM. But there is definitely no need for an ORM here because there is no domain model.

So, what are the alternatives?

Martin Fowler provides a number of alternatives in his book Patterns of Enterprise Application Architecture - under Data Source Architectural Patterns.

Rather than enumerate the high-level patterns that Martin Fowler has already suggested, I’ll jump into technology choices instead. Assuming that the ORM of choice was originally NHibernate, you could just choose a simpler ORM such as Entity Framework. This will certainly make generating the mapping code far simpler than learning NHibernate’s configuration files. But, even that could be argued as overkill.

Perhaps Active Record would be a good fit, but again this is also a suitable alternative when there is behavior inside the objects, thus potentially overkill.

The simplest solution that I would advocate when there is no behavior in the domain model is a Typed DataSet. First of all, a typed dataset can be generated from an existing database and this yields the CRUD operations for all of the tables, as well as locally maintaining referential integrity without having to hit the database again.

Furthermore, if deemed necessary, the messy auto-generated code can be hidden behind neat interfaces for each domain object by adding a partial definition for each class generated – as long as the properties match the type and name of those generated.

What we are creating with this pattern is merely Data Transfer Objects (DTOs) – which is pretty much what we started with because DTOs are objects without any behavior. We’re just admitting the fact and making design decisions based on that admission.

Perhaps you may think that there will be a future requirement for behavior in your domain model which merely hasn’t yet been fulfilled. Perhaps, but until that day comes, you would save a lot of effort by starting with the simplest thing that works.

Skyhooks vs Cranes

Daniel C. Dennett wrote in his 1995 book Darwin’s Dangerous Idea [emphasis author's]

“A skyhook is … an exception to the principle that all design, and apparent design, is ultimately the result of mindless, motiveless mechanicity. A crane, in contrast, is a subprocess or special feature of a design process that can be demonstrated to permit the local speeding up of the basic, slow process of natural selection, and that can be demonstrated to be itself the predictable (or retrospectively explicable) product of the basic process.”

Daniel C. Dennett, Darwin’s Dangerous Idea,1995 (p76)

Basically, a skyhook is a way to explain something without reference to a prior antecedent. Conversely, cranes have explicable antecedents – perhaps until arriving at some primary axiom.

This is a useful analogy in programming, too. Skyhooks are a code smell; indicative of a deeper problem. All skyhooks should be replaced with appropriate cranes.

A skyhook makes your code difficult to mock. Examples of skyhooks are:

  • Static methods
  • Singletons
  • Object construction using new
  • Extension methods
Each of these make testing more difficult* by hindering your ability to inject mocks into your code, they are skyhooks and thus they are undesirable. Each is used ex nihilo – from nothing.
Thankfully, each of these can be replaced by a suitable crane which will facilitate some kind of external injection (ie: used ex materia – from something).
  • Interfaces
  • Dependency Injection
  • Inversion of Control
  • Factories
Let’s take an example of each skyhook and change it so that we use hooks instead.
public class UsersModule : IModule
{
	public void Initialize()
	{
		var unityContainer = ServiceLocator.Current.GetInstance<IUnityContainer>();
		unityContainer.RegisterType<object, UsersDocumentContent>(RegionNames.ModuleDocumentContentRegion(ModuleName));
		this.currentUser = new User();
	}
}
This method contains all four of the aforementioned skyhooks (see if you can spot where before continuing).
Firstly, the use of ServiceLocator is an example of why the Singleton pattern is my pet hate. I firmly consider it an anti-pattern.
Granted – in this instance – the ServiceLocator has a SetLocatorProvider method which unit tests can use to inject the locator, this is a less-than-desirable way of giving a class a service locator. Furthermore, you’ve now given this code the keys to the safe with regard to what services it can acquire. I’d far rather be explicit with the dependencies that I a class requires:
public class UsersModule : IModule
{
	public UsersModule(IUnityContainer unityContainer)
	{
		this.unityContainer = unityContainer;
	}

	public void Initialize()
	{
		this.unityContainer.RegisterType<object, UsersDocumentContent>(RegionNames.ModuleDocumentContentRegion(ModuleName));
		this.currentUser = new User();
	}

	private IUnityContainer unityContainer;
}
Now, the specific dependency has been constructor-injected, allowing unit tests to provide a suitable mock.
The second and third skyhooks are similarly extracted:
public class UsersModule : IModule
{
	public UsersModule(IUnityContainer unityContainer, IRegionNameProvider regionNameProvider, IUserFactory userFactory)
	{
		this.unityContainer = unityContainer;
		this.regionNameProvider = userFactoy;
		this.userFactory = userFactory;
	}

	public void Initialize()
	{
		this.unityContainer.RegisterType<object, UsersDocumentContent>(this.regionNameProvider.ModuleDocumentContentRegion(ModuleName));
		this.currentUser = this.userFactory.CreateNew();
	}

	private IUnityContainer unityContainer;
	private IRegionNameProvider;
	private IUserFactory userFactory;
}
I wouldn’t worry about the three constructor parameters – they’ll be injected by your IoC container.
The final skyhook, the RegisterType extension method, is a specialization of the static method skyhook (inasmuch as extension methods are implemented using static methods, an unfortunate design decision by Microsoft). Thankfully, extension methods must operate only on the public interface of the extended interface. This means that the call will likely result in an equivalent call to a method on the interface that was injected.
In conclusion, whenever you spot a skyhook, replace it with a crane.
* Some mocking frameworks, such as TypeMock, are able to mock skyhooks. However, this should only be considered if the skyhooks are in 3rd-party, unchangeable, code.

Why does Prism 4 register IRegionNavigationService as TransientLifetimeManager?

Ugh, leaky abstraction alert.

I was hoping to pop up some kind of exception message box whenever navigation failed. So, I retrieve the RegionNavigationService and register for the NavigationFailed event:

public void Initialization()
{
	var regionNavigationService = this.serviceLocator.GetInstance<IRegionNavigationService>();
	regionNavigationService.NavigationFailed += (sender, args) =>
	{
		var errorReportingService = this.serviceLocator.GetInstance<IErrorReportingService>();
		errorReportingService.ReportException(args.Error);
	}
}

Sadly, as soon as we fall out of scope of the Initialization method, regionNavigationService can be garbage collected.

The IRegionNavigationService is registered with the TransientLifetimeManager, meaning that each request for such an interface will merely instantiate a new object of the registered implementing type.

As a result, the event handler will never be fired because the regionNavigationService has been garbage collected.

Looking at the MSDN documentation for the IRegionNavigationService, NavigationFailed is just one of three events available on this interface, along with Navigated and Navigating.

These events can only be handled in close proximity to the original navigation request. You must retrieve the service from the container, register handlers for any events you are interested in and then make a navigation request.

What I was trying to do was supply a global navigation error handler, which will not work because the instance of the navigation service which I am listening to is different from the one which I am using to navigate from.