A common criticism of loosely coupled code is that it’s harder to understand. How do you see the big picture of an application when loose coupling is everywhere? When the entire code base has been programmed against interfaces instead of concrete classes, how do we understand how the objects are wired and how they interact?

In this post, I’ll provide answers on various levels, from high-level architecture over object-oriented principles to more nitty-gritty code. Before I do that, however, I’d like to pose a set of questions you should always be prepared to answer.

Mu

My first reaction to that sort of question is: you say loosely coupled code is harder to understand. Harder than what?

If we are talking about a non-trivial application, odds are that it’s going to take some time to understand the code base – whether or not it’s loosely coupled. Agreed: understanding a loosely coupled code base takes some work, but so does understanding a tightly coupled code base. The question is whether it’s harder to understand a loosely coupled code base?

Imagine that I’m having a discussion about this subject with Mary Rowan from my book.

Mary: “Loosely coupled code is harder to understand.”

Me: “Why do you think that is?”

Mary: “It’s very hard to navigate the code base because I always end up at an interface.”

Me: “Why is that a problem?”

Mary: “Because I don’t know what the interface does.”

At this point I’m very tempted to answer Mu. An interfaces doesn’t do anything – that’s the whole point of it. According to the Liskov Substitution Principle (LSP), a consumer shouldn’t have to care about what happens on the other side of the interface.

However, developers used to tightly coupled code aren’t used to think about services in this way. They are used to navigate the code base from consumer to service to understand how the two of them interact, and I will gladly admit this: in principle, that’s impossible to do in a loosely coupled code base. I’ll return to this subject in a little while, but first I want to discuss some strategies for understanding a loosely coupled code base.

Architecture and Documentation

Yes: documentation. Don’t dismiss it. While I agree with Uncle Bob and like-minded spirits that the code is the documentation, a two-page document that outlines the Big Picture might save you from many hours of code archeology.

The typical agile mindset is to minimize documentation because it tends to lose touch with the code base, but even so, it should be possible to maintain a two-page high-level document so that it stays up to date. Consider the alternative: if you have so much architectural churn that even a two-page overview regularly falls behind, then you’re probably having a greater problem than understanding your loosely coupled code base.

Maintaining such a document isn’t adverse to the agile spirit. You’ll find the same advice in Lean Architecture (p. 127). Don’t underestimate the value of such a document.

See the Forest Instead of the Trees

Understanding a loosely coupled code base typically tends to require a shift of mindset.

Recall my discussion with Mary Rowan. The criticism of loose coupling is that it’s difficult to understand which collaborators are being invoked. A developer like Mary Rowan is used to learn a code base by understanding all the myriad concrete details of it. In effect, while there may be ‘classes’ around, there are no abstractions in place. In order to understand the behavior of a user interface element, it’s necessary to also understand what’s happening in the database – and everything in between.

A loosely coupled code base shouldn’t be like that.

The entire purpose of loose coupling is that we should be able to reason about a part (a ‘unit’, if you will) without understanding the whole.

In a tightly coupled code base, it’s often impossible to see the forest for the trees. Although we developers are good at relating to details, a tightly coupled code base requires us to be able to contain the entire code base in our heads in order to understand it. As the size of the code base grows, this becomes increasingly difficult.

In a loosely coupled code base, on the other hand, it should be possible to understand smaller parts in isolation. However, I purposely wrote “should be”, because that’s not always the case. Often, a so-called “loosely coupled” code base violates basic principles of object-oriented design.

RAP

The criticism that it’s hard to see “what’s on the other side of an interface” is, in my opinion, central. It betrays a mindset which is still tightly coupled.

In many code bases there’s often a single implementation of a given interface, so developers can be forgiven if they think about an interface as only a piece of friction that prevents them from reaching the concrete class on the other side. However, if that’s the case with most of the interfaces in a code base, it signifies a violation of the Reused Abstractions Principle (RAP) more than it signifies loose coupling.

Jim Cooper, a reader of my book, put it quite eloquently on the book’s forum:

“So many people think that using an interface magically decouples their code. It doesn't. It only changes the nature of the coupling. If you don't believe that, try changing a method signature in an interface - none of the code containing method references or any of the implementing classes will compile. I call that coupled”

Refactoring tools aside, I completely agree with this statement. The RAP is a test we can use to verify whether or not an interface is truly reusable – what better test is there than to actually reuse your interfaces?

The corollary of this discussion is that if a code base is massively violating the RAP then it’s going to be hard to understand. It has all the disadvantages of loose coupling with few of the benefits. If that’s the case, you would gain more benefit from making it either more tightly coupled or truly loosely coupled.

What does “truly loosely coupled” mean?

LSP

According to the LSP a consumer must not concern itself with “what’s on the other side of the interface”. It should be possible to replace any implementation with any other implementation of the same interface without changing the correctness of the program.

This is why I previously said that in a truly loosely coupled code base, it isn’t ‘hard’ to understand “what’s on the other side of the interface” – it’s impossible. At design-time, there’s nothing ‘behind’ the interface. The interface is what you are programming against. It’s all there is.

Mary has been listening to all of this, and now she protests:

Mary: “At run-time, there’s going to be a concrete class behind the interface.”

Me (being annoyingly pedantic): “Not quite. There’s going to be an instance of a concrete class which the consumer invokes via the interface it implements.”

Mary: “Yes, but I still need to know which concrete class is going to be invoked.”

Me: “Why?”

Mary: “Because otherwise I don’t know what’s going to happen when I invoke the method.”

This type of answer often betrays a much more fundamental problem in a code base.

CQS

Now we are getting into the nitty-gritty details of class design. What would you expect that the following method does?

public List<Order> GetOpenOrders(Customer customer)

The method name indicates that it gets open orders, and the signature seems to back it up. A single database query might be involved, since this looks a lot like a read-operation. A quick glance at the implementation seems to verify that first impression:

public List<Order> GetOpenOrders(Customer customer)

{

    var orders = GetOrders(customer);

    return (from o in orders

            where o.Status == OrderStatus.Open

            select o).ToList();

}

Is it safe to assume that this is a side-effect-free method call? As it turns out, this is far from the case in this particular code base:

private List<Order> GetOrders(Customer customer)

{

    var gw = new CustomerGateway(this.ConnectionString);

    var orders = gw.GetOrders(customer);

    AuditOrders(orders);

    FixCustomer(gw, orders, customer);

    return orders;

}

The devil is in the details. What does AuditOrders do? And what does FixCustomer do? One method at a time:

private void AuditOrders(List<Order> orders)

{

    var user = Thread.CurrentPrincipal.Identity.ToString();

    var gw = new OrderGateway(this.ConnectionString);

    foreach (var o in orders)

    {

        var clone = o.Clone();

        var ar = new AuditRecord

        {

            Time = DateTime.Now,

            User = user

        };

        clone.AuditTrail.Add(ar);

        gw.Update(clone);

        // We don't want the consumer to see the audit trail.

        o.AuditTrail.Clear();

    }

}

OK, it turns out that this method actually makes a copy of each and every order and updates that copy, writing it back to the database in order to leave behind an audit trail. It also mutates each order before returning to the caller. Not only does this method result in an unexpected N+1 problem, it also mutates its input, and perhaps even more surprising, it’s leaving the system in a state where the in-memory object is different from the database. This could lead to some pretty interesting bugs.

Then what happens in the FixCustomer method? This:

// Fixes the customer status field if there were orders

// added directly through the database.

private static void FixCustomer(CustomerGateway gw,

    List<Order> orders, Customer customer)

{

    var total = orders.Sum(o => o.Total);

    if (customer.Status != CustomerStatus.Preferred

        && total > PreferredThreshold)

    {

        customer.Status = CustomerStatus.Preferred;

        gw.Update(customer);

    }

}

Another potential database write operation, as it turns out – complete with an apology. Now that we’ve learned all about the details of the code, even the GetOpenOrders method is beginning to look suspect. The GetOrders method returns all orders, with the side effect that all orders were audited as having been read by the user, but the GetOpenOrders filters the output. In the end, it turns out that we can’t even trust the audit trail.

While I must apologize for this contrived example of a Transaction Script, it’s clear that when code looks like that, it’s no wonder why developers think that it’s necessary to contain the entire code base in their heads. When this is the case, interfaces are only in the way.

However, this is not the fault of loose coupling, but rather a failure to adhere to the very fundamental principle of Command-Query Separation (CQS). You should be able to tell from the method signature alone whether invoking the method will or will not have side-effects. This is one of the key messages from Clean Code: the method name and signature is an abstraction. You should be able to reason about the behavior of the method from its declaration. You shouldn’t have to read the code to get an idea about what it does.

Abstractions always hide details. Method declarations do too. The point is that you should be able to read just the method declaration in order to gain a basic understanding of what’s going on. You can always return to the method’s code later in order to understand detail, but reading the method declaration alone should provide the Big Picture.

Strictly adhering to CQS goes a long way in enabling you to understand a loosely coupled code base. If you can reason about methods at a high level, you don’t need to see “the other side of the interface” in order to understand the Big Picture.

Stack Traces

Still, even in a loosely coupled code base with great test coverage, integration issues arise. While each class works fine in isolation, when you integrate them, sometimes the interactions between them cause errors. This is often because of incorrect assumptions about the collaborators, which often indicates that the LSP was somehow violated.

To understand why such errors occur, we need to understand which concrete classes are interacting. How do we do that in a loosely coupled code base?

That’s actually easy: look at the stack trace from your error report. If your error report doesn’t include a stack trace, make sure that it’s going to do that in the future.

The stack trace is one of the most important troubleshooting tools in a loosely coupled code base, because it’s going to tell you exactly which classes were interacting when an exception was thrown.

Furthermore, if the code base also adheres to the Single Responsibility Principle and the ideals from Clean Code, each method should be very small (under 15 lines of code). If that’s the case, you can often understand the exact nature of the error from the stack trace and the error message alone. It shouldn’t even be necessary to attach a debugger to understand the bug, but in a pinch, you can still do that.

Tooling

Returning to the original question, I often hear people advocating tools such as IDE add-ins which support navigation across interfaces. Such tools might provide a menu option which enables you to “go to implementation”. At this point it should be clear that such a tool is mainly going to be helpful in code bases that violate the RAP.

(I’m not naming any particular tools here because I’m not interested in turning this post into a discussion about the merits of various specific tools.)

Conclusion

It’s the responsibility of the loosely coupled code base to make sure that it’s easy to understand the Big Picture and that it’s easy to work with. In the end, that responsibility falls on the developers who write the code – not the developer who’s trying to understand it.

SOLID is a set of principles that, if applied consistently, has some surprising effect on code. In a previous post I provided a sketch of what it means to meticulously apply the Single Responsibility Principle. In this article I will describe what happens when you follow the Open/Closed Principle (OCP) to its logical conclusion.

In case a refresher is required, the OCP states that a class should be open for extension, but closed for modification. It seems to me that people often forget the second part. What does it mean?

It means that once implemented, you shouldn’t touch that piece of code ever again (unless you need to correct a bug).

Then how can new functionality be added to a code base? This is still possible through either inheritance or polymorphic recomposition. Since the L in SOLID signifies the Liskov Substitution Principle, SOLID code tends to be based on loosely coupled code composed into an application through copious use of interfaces – basically, Strategies injected into other Strategies and so on (also due to Dependency Inversion Principle). In order to add functionality, you can create new implementations of these interfaces and redefine the application’s Composition Root. Perhaps you’d be wrapping existing functionality in a Decorator or adding it to a Composite.

Once in a while, you’ll stop using an old implementation of an interface. Should you then delete this implementation? What would be the point? At a certain point in time, this implementation was valuable. Maybe it will become valuable again. Leaving it as an potential building block seems a better choice.

Thus, if we think about working with code as a CRUD endeavor, SOLID code can be Created and Read, but never Updated or Deleted. In other words, true SOLID code is append-only code.

Example: Changing AutoFixture’s Number Generation Algorithm

In early 2011 an issue was reported for AutoFixture: Anonymous numbers were created in monotonically increasing sequences, but with separate sequences for each number type:

integers: 1, 2, 3, 4, 5, …

decimals: 1.0, 2.0, 3.0, 4.0, 5.0, …

and so on. However, the person reporting the issue thought it made more sense if all numbers shared a single sequence. After thinking about it a little while, I agreed.

Because the AutoFixture code base is fairly SOLID we decided to leave the old implementations in place and implement the new behavior in new classes.

The old behavior was composed from a set of ISpecimenBuilders. As an example, integers were generated by this class:

public class Int32SequenceGenerator : ISpecimenBuilder

{

    private int i;

    public int CreateAnonymous()

    {

        return Interlocked.Increment(ref this.i);

    }

    public object Create(object request,

        ISpecimenContext context)

    {

        if (request != typeof(int))

        {

            return new NoSpecimen(request);

        }

        return this.CreateAnonymous();

    }

}

Similar implementations generated decimals, floats, doubles, etc. Instead of modifying any of these classes, we left them in the code base and created a new ISpecimenBuilder that generates all numbers from a single sequence:

public class NumericSequenceGenerator : ISpecimenBuilder

{

    private int value;

    public object Create(object request,

        ISpecimenContext context)

    {

        var type = request as Type;

        if (type == null)

            return new NoSpecimen(request);

        return this.CreateNumericSpecimen(type);

    }

    private object CreateNumericSpecimen(Type request)

    {

        var typeCode = Type.GetTypeCode(request);

        switch (typeCode)

        {

            case TypeCode.Byte:

                return (byte)this.GetNextNumber();

            case TypeCode.Decimal:

                return (decimal)this.GetNextNumber();

            case TypeCode.Double:

                return (double)this.GetNextNumber();

            case TypeCode.Int16:

                return (short)this.GetNextNumber();

            case TypeCode.Int32:

                return this.GetNextNumber();

            case TypeCode.Int64:

                return (long)this.GetNextNumber();

            case TypeCode.SByte:

                return (sbyte)this.GetNextNumber();

            case TypeCode.Single:

                return (float)this.GetNextNumber();

            case TypeCode.UInt16:

                return (ushort)this.GetNextNumber();

            case TypeCode.UInt32:

                return (uint)this.GetNextNumber();

            case TypeCode.UInt64:

                return (ulong)this.GetNextNumber();

            default:

                return new NoSpecimen(request);

        }

    }

    private int GetNextNumber()

    {

        return Interlocked.Increment(ref this.value);

    }

}

Adding a new class in itself has no effect, so in order to recompose the default behavior of AutoFixture, we changed a class called DefaultPrimitiveBuilders by removing the old ISpecimenBuilders like Int32SequenceGenerator and instead adding NumericSequenceGenerator:

yield return new StringGenerator(() => 

    Guid.NewGuid());

yield return new ConstrainedStringGenerator();

yield return new StringSeedRelay();

yield return new NumericSequenceGenerator();

yield return new CharSequenceGenerator();

yield return new RangedNumberGenerator();

// even more builders...

NumericSequenceGenerator is the fourth class being yielded here. Before we added NumericSequenceGenerator, this class instead yielded Int32SequenceGenerator and similar classes. These were removed.

The DefaultPrimitiveBuilders class is part of AutoFixture’s default Facade and is the closest we get to a Composition Root for the library. Recomposing this Facade enabled us to change the behavior of AutoFixture without modifying (other) existing classes.

As Enrico (who implemented this change) points out, the beauty is that the previous behavior is still in the box, and all it takes is a single method call to bring it back:

var fixture = new Fixture().Customize(

    new NumericSequencePerTypeCustomization());

The only class we had to modify was the DefaultPrimitiveBuilders, which is where the object graph is composed. In applications this corresponds to the Composition Root, so even in the face of SOLID code, you still need to modify the Composition Root in order to recompose the application. However, use of a good DI Container and a strong set of conventions can do much to minimize the required editing of such a class.

SOLID versus Refactoring

SOLID is a goal I strive towards in the way I write code and design APIs, but I don’t think I’ve ever written a significant code base which is perfectly SOLID. While I consider AutoFixture a ‘fairly’ SOLID code base, it’s not perfect, and I’m currently performing some design work in order to change some abstractions for version 3.0. This will require changing some of the existing types and thereby violating the OCP.

It’s worth noting that as long as you can stick with the OCP you can avoid introducing breaking changes. A breaking change is also an OCP violation, so adhering to the OCP is more than just an academic exercise – particularly if you write reusable libraries.

Still, while none of my code is perfect and I occasionally have to refactor, I don’t refactor much. By definition, refactoring means violating the OCP, and while I have nothing against refactoring code when it’s required, I much prefer putting myself in a situation where it’s rarely necessary in the first place.

I’ve often been derided for my lack of use of Resharper. When replying that I have little use for Resharper because I write SOLID code and thus don’t do much refactoring, I’ve been ridiculed for being totally clueless. People don’t realize the intimate relationship between SOLID and refactoring. I hope this post has helped highlight that connection.

Here’s a question I often get:

“Should I test my DI Container configuration?”

The motivation for asking mostly seems to be that people want to know whether or not their applications are correctly wired. That makes sense.

A related question I also often get is whether or not a particular container has a self-test feature? In this post I’ll attempt to answer both questions.

Container Self-testing

Some DI Containers have a method you can invoke to make it perform a consistency check on itself. As an example, StructureMap has the AssertConfigurationIsValid method that, according to documentation does “a full environment test of the configuration of [the] container.” It will “try to create every configured instance [...]”

Calling the method is really easy:

container.AssertConfigurationIsValid();

Such a self-test can often be an expensive operation (not only for StructureMap, but in general) because it’s basically attempting to create an instance of each and every Service registered in the container. If the configuration is large, it’s going to take some time, but it’s still going to be faster than performing a manual test of the application.

Two questions remain: Is it worth invoking this method? Why don’t all containers have such a method?

The quick answer is that such a method is close to worthless, which also explains why many containers don’t include one.

To understand the answer, consider the set of all components contained in the container in this figure:

The container contains the set of components IFoo, IBar, IBaz, Foo, Bar, Baz, and Qux so a self-test will try to create a single instance of each of these seven types. If all seven instances can be created, the test succeeds.

All this accomplishes is to verify that the configuration is internally consistent. Even so, an application could require instances of the ICorge, Corge or Grault types which are completely external to the configuration, in which case resolution would fail.

Even more subtly, resolution would also fail whenever the container is queried for an instance of IQux, since this interface isn’t part of the configuration, even though it’s related to the concrete Qux type which is registered in the container. A self-test only verifies that the concrete Qux class can be resolved, but it never attempts to create an instance of the IQux interface.

In short, the fact that a container’s configuration is internally consistent doesn’t guarantee that all services required by an application can be served.

Still, you may think that at least a self-test can constitute an early warning system: if the self-test fails, surely it must mean that the configuration is invalid? Unfortunately, that’s not true either.

If a container is being configured using Auto-registration/Convention over Configuration to scan one or more assemblies and register certain types contained within, chances are that ‘too many’ types will end up being registered – particularly if one or more of these assemblies are reusable libraries (as opposed to application-specific assemblies). Often, the number of redundant types added is negligible, but they may make the configuration internally inconsistent. However, if the inconsistency only affects the redundant types, it doesn’t matter. The container will still be able to resolve everything the current application requires.

Thus, a container self-test method is worthless.

Then how can the container configuration be tested?

Explicit Testing of Container Configuration

Since a container self-test doesn’t achieve the desired goal, how can we ensure that an application can be composed correctly?

One option is to write an automated integration test (not a unit test) for each service that the application requires. Still, if done manually, you run the risk of forgetting to write a test for a specific service. A better option is to come up with a convention so that you can identify all the services required by a specific application, and then write a convention-based test to verify that the container can resolve them all.

Will this guarantee that the application can be correctly composed?

No, it only guarantees that it can be composed – not that this composition is correct.

Even when a composed instance can be created for each and every service, many things may still be wrong:

• Composition is just plain wrong:
  • Decorators may be missing
  • Decorators may have been added in the wrong order
  • The wrong services are injected into consumers (this is more likely to happen when you follow the Reused Abstractions Principle, since there will be multiple concrete implementations of each interface)
• Configuration values like connection strings and such are incorrect – e.g. while a connection string is supplied to a constructor, it may not contain the correct values.
• Even if everything is correctly composed, the run-time environment may prevent the application from working. As an example, even if an injected connection string is correct, there may not be any connection to the database due to network or security misconfiguration.

In short, a Subcutaneous Test or full System Test is the only way to verify that everything is correctly wired. However, if you have good test coverage at the unit test level, a series of Smoke Tests is all that you need at the System Test level because in general you have good reason to believe that all behavior is correct. The remaining question is whether all this correct behavior can be correctly connected, and that tends to be an all-or-nothing proposition.

Conclusion

While it would be possible to write a set of convention-based integration tests to verify the configuration of a DI Container, the return of investment is too low since it doesn’t remove the need for a set of Smoke Tests at the System Test level.

Recently I received a question from Kelly Sommers about good ways to refactor away from Factory Overload. Basically, she’s working in a code base where there’s an explosion of Abstract Factories which seems to be counter-productive. In this post I’ll take a look at the example problem and propose a set of alternatives.

An Abstract Factory (and its close relative Product Trader) can serve as a solution to various challenges that come up when writing loosely coupled code (chapter 6 of my book describes the most common scenarios). However, introducing an Abstract Factory may be a leaky abstraction, so don’t do it blindly. For example, an Abstract Factory is rarely the best approach to address lifetime management concerns. In other words, the Abstract Factory has to make sense as a pure model element.

That’s not the case in the following example.

Problem Statement

The question centers around a code base that integrates with a database closely guarded by DBA police. Apparently, every single database access must happen through a set of very fine-grained stored procedures.

For example, to update the first name of a user, a set of stored procedures exist to support this scenario, depending on the context of the current application user:

As this table demonstrates, not only is there a stored procedure for each user context, but the parameter name differs as well. However, in this particular case it seems as though there’s a pattern to the names.

If this pattern is consistent, I think the easiest way to address these variations would be to algorithmically build the strings from a couple of templates.

However, this is not the route taken by Kelly’s team, so I assume that things are more complicated than that; apparently, a templated approach is not viable, so for the rest of  this article I’m going to assume that it’s necessary to write at least some code to address each case individually.

The current solution that Kelly’s team has implemented is to use an Abstract Factory (Product Trader) to translate the user type into an appropriate IUserFirstNameModifier instance. From the consuming code, it looks like this:

var modifier = factory.Create(UserTypes.Admin);

modifier.Commit("first");

where the factory variable is an instance of the IUserFirstNameModifierFactory interface. This is certainly loosely coupled, but looks like a leaky abstraction. Why is a factory needed? It seems that its single responsibility is to translate a UserTypes instance (an enum) into an IUserFirstNameModifier. There’s a code smell buried here – try to spot it before you read on :)

Proposed Solution

Kelly herself suggests an alternative involving a concrete Builder which can create instances of a single concrete UserFirstNameModifier with or without an implicit conversion:

// Implicit conversion.

UserFirstNameModifier modifier1 = 

    builder.WithUserType(UserTypes.Guest);

// Without implicit conversion.

var modifier2 = builder

    .WithUserType(UserTypes.Restricted)

    .Create();

While this may seem to reduce the number of classes involved, it has several drawbacks:

• First of all, the Fluent Builder pattern implies that you can forgo invoking any of the WithXyz methods (WithUserType) and just accept all the default values encapsulated in the builder. This again implies that there’s a default user type, which may or may not make sense in that particular domain. Looking at Kelly’s code, UserTypes is an enum (and thus has a default value), so if WithUserType isn’t invoked, the Create method defaults to UserTypes.Admin. That’s a bit too implicit for my taste.
• Since all involved classes are now concrete, the proposed solution isn’t extensibile (and by corollary hard to unit test).
• The builder is essentially a big switch statement.

Both the current implementation and the proposed solution involves passing an enum as a method parameter to a different class. If you’ve read and memorized Refactoring you should by now have recognized both a code smell and the remedy.

Alternative 1a: Make UserType Polymorphic

The code smell is Feature Envy and a possible refactoring is to replace the enum with a Strategy. In order to do that, an IUserType interface is introduced:

public interface IUserType

{

    IUserFirstNameModifer CreateUserFirstNameModifier();

}

Usage becomes as simple as this:

var modifier = userType.CreateUserFirstNameModifier();

Obviously, more methods can be added to IUserType to support other update operations, but care should be taken to avoid creating a Header Interface.

While this solution is much more object-oriented, I’m still not quite happy with it, because apparently, the context is a CQRS style architecture. Since an update operation is essentially a Command, then why model the implementation along the lines of a Query? Both Abstract Factory and Factory Method patterns represent Queries, so it seems redundant in this case. It should be possible to apply the Hollywood Principle here.

Alternative 1b: Tell, Don’t Ask

Why have the user type return an modifier? Why can’t it perform the update itself? The IUserType interface should be changed to something like this:

public interface IUserType

{

    void CommitUserFirtName(string firstName);

}

This makes it easier for the consumer to commit the user’s first name because it can be done directly on the IUserType instance instead of first creating the modifier.

It also makes it much easier to unit test the consumer because there’s no longer a mix of Command and Queries within the same method. From Growing Object-Oriented Software we know that Queries should be modeled with Stubs and Commands with Mocks, and if you’ve ever tried mixing the two you know that it’s a sort of interaction that should be minimized.

Alternative 2a: Distinguish by Type

While I personally like alternative 1b best, it may not be practical in all situations, so it’s always valuable to examine other alternatives.

The root cause of the problem is that there’s a lot of stored procedures. I want to reiterate that I still think that the absolutely easiest solution would be to generate a SqlCommand from a string template, but given that this article assumes that this isn’t possible or desirable, it follows that code must be written for each stored procedure.

Why not simply define an interface for each one? As an example, to update the user’s first name in the context of being an ‘Admin’ user, this Role Interface can be used:

public interface IUserFirstNameAdminModifier

{

    void Commit(string firstName);

}

Similar interfaces can be defined for the other user types, such as IUserFirstNameRestrictedModifier, IUserFirstNameGuestModifier and so on.

This is a very simple solution; it’s easy to implement, but risks violating the Reused Abstractions Principle (RAP).

Alternative 2b: Distinguish by Generic Type

The problem with introducing interfaces like IUserFirstNameAdminModifier, IUserFirstNameRestrictedModifier, IUserFirstNameGuestModifier etc. is that they differ only by name. The Commit method is the same for all these interfaces, so this seems to violate the RAP. It’d be better to merge all these interfaces into a single interface, which is what Kelly’s team is currently doing. However, the problem with this is that the type carries no information about the role that the modifier is playing.

Another alternative is to turn the modifier interface into a generic interface like this:

public interface IUserFirstNameModifier<T> 

    where T : IUserType

{

    void Commit(string firstName);

}

The IUserType is a Marker Interface, so .NET purists are not going to like this solution, since the .NET Type Design Guidelines recommend against using Marker Interfaces. However, it’s impossible to constrain a generic type argument against an attribute, so the party line solution is out of the question.

This solution ensures that consumers can now have dependencies on IUserFirstNameModifier<AdminUserType>, IUserFirstNameModifier<RestrictedUserType>, etc.

However, the need for a marker interface gives off another odeur.

Alternative 3: Distinguish by Role

The problem at the heart of alternative 2 is that it attempts to use the type of the interfaces as an indicator of the roles that Services play. It’s seems that making the type distinct works against the RAP, but when the RAP is applied, the type becomes ambiguous.

However, as Ted Neward points out in his excellent series on Multiparadigmatic .NET, the type is only one axis of variability among many. Perhaps, in this case, it may be much easier to use the name of the dependency to communicate its role instead of the type.

Given a single, ambiguous IUserFirstNameModifier interface (just as in the original problem statement), a consumer can distinguish between the various roles of modifiers by their names:

public partial class SomeConsumer

{

    private readonly IUserFirstNameModifier adminModifier;

    private readonly IUserFirstNameModifier guestModifier;

    public SomeConsumer(

        IUserFirstNameModifier adminModifier,

        IUserFirstNameModifier guestModifier)

    {

        this.adminModifier = adminModifier;

        this.guestModifier = guestModifier;

    }

    public void DoSomething()

    {

        if (this.UseAdmin)

            this.adminModifier.Commit("first");

        else

            this.guestModifier.Commit("first");

    }

}

Now it’s entirely up to the Composition Root to compose SomeConsumer with the correct modifiers, and while this can be done manually, it’s an excellent case for a DI Container and a bit of Convention over Configuration.

Conclusion

I’m sure that if I’d spent more time analyzing the problem I could have come up with more alternatives, but this post is becoming long enough already.

Of the alternatives I’ve suggested here, I prefer 1b or 3, depending on the exact requirements.

Asynchronous message passing combined with eventual consistency makes it possible to build very scalable systems. However, sometimes eventual consistency isn’t appropriate in parts of the system, while it’s acceptable in other parts. How can a consistent architecture be defined to fit both ACID and eventual consistency? This article provides an answer.

The case of an online game

Last week I visited Pixel Pandemic, a company that produces browser-based MMORPGs. Since each game world has lots of players who can all potentially interact with each other, scalability is very important.

In traditional line of business applications, eventual consistency is often an excellent fit because the application is a projection of the real world. My favorite example is an inventory system: it models what’s going on in one or more physical warehouses, but the real world is the ultimate source of truth. A warehouse worker might accidentally drop and damage some of the goods, in which case the application must adjust after the fact.

In other words, the information contained within line of business applications tend to lag after the real world. It’s impossible to guarantee that the application is always consistent with the real world, so eventual consistency is a natural fit.

That’s not the case with an online game world. The game world itself is the source of truth, and it must be internally consistent at all times. As an example, in Zombie Pandemic, players fight against zombies and may take damage along the way. Players can heal themselves, but they would prefer (I gather) that the healing action takes place immediately, and not some time in the future where the character might be dead. Similarly, when a player hits a zombie, they’d prefer to apply the damage immediately. (However, I think that even here, eventual consistency might provide some interesting game mechanics, but that’s another discussion.)

While discussing these matters with the nice people in Pixel Pandemic, it turned out that while some parts of the game world have to be internally consistent, it’s perfectly acceptable to use eventual consistency in other cases. One example is the game’s high score table. While a single player should have a consistent view of his or her own score, it’s acceptable if the high score table lags a bit.

At this point it seemed clear that this particular online game could use an appropriate combination of ACID and eventual consistency, and I think this conclusion can be generalized. The question now becomes: how can a consistent architecture encompass both types of consistency?

Problem statement

With the above example scenario in mind the problem statement can be generalized:

Given that an application should apply a mix of ACID and eventual consistency, how can a consistent architecture be defined?

Keep in mind that ACID consistency implies that all writes to a transactional resource must take place as a blocking method call. This seems to be at odds with the concept of asynchronous message passing that works so well with eventual consistency.

However, an application architecture where blocking ACID calls are fundamentally different than asynchronous message passing isn’t really an architecture at all. Developers will have to decide up-front whether or not a given operation is or isn’t synchronous, so the ‘architecture’ offers little implementation guidance. The end result is likely to be a heterogeneous mix of Services, Repositories, Units of Work, Message Channels, etc. A uniform principle will be difficult to distill, and the whole thing threatens to devolve into Spaghetti Code.

The solution turns out to be not at all difficult, but it requires that we invert our thinking a bit. Most of us tend to think about synchronous code first. When we think about code performing synchronous work it seems difficult (perhaps even impossible) to retrofit asynchrony to that model. On the other hand, the converse isn’t true.

Given an asynchronous API, it’s trivial to provide a synchronous, blocking implementation.

Adopting an architecture based on asynchronous message passing (the Pipes and Filters architecture) enables both scenarios. Eventual consistency can be achieved by passing messages around on persistent queues, while ACID consistency can be achieved by handling a message in a blocking call that enlists a (potentially distributed) transaction.

An example seems to be in order here.

Example: keeping score

In the online game world, each player accumulates a score based on his or her actions. From the perspective of the player, the score should always be consistent. When you defeat the zombie boss, you want to see the result in your score right away. That sounds an awful lot like the Player is an Aggregate Root and the score is part of that Entity. ACID consistency is warranted whenever the Player is updated.

On the other hand, each time a score changes it may influence the high score table, but this doesn’t need to be ACID consistent; eventual consistency is fine in this case.

Once again, polymorphism comes to the rescue.

Imagine that the application has a GameEngine class that handles updates in the game. Using an injected IChannel<PointsChangedEvent> it can update the score for a player as simple as this:

/* Lots of other interesting things happen

    * here, like calculating the new score... */

var cmd =

    new ScoreChangedEvent(this.playerId, score);

this.pointsChannel.Send(cmd);

The Send method returns void, so it’s a good example of a naturally asynchronous API. However, the implementation must do two things:

• Update the Player Aggregate Root in a transaction
• Update the high score table (eventually)

That’s two different types of consistency within the same method call.

The first step to enable this is to employ the trusty old Composite design pattern:

public class CompositeChannel<T> : IChannel<T>

{

    private readonly IEnumerable<IChannel<T>> channels;

    public CompositeChannel(params IChannel<T>[] channels)

    {

        this.channels = channels;

    }

    public void Send(T message)

    {

        foreach (var c in this.channels)

        {

            c.Send(message);

        }

    }

}

With a Composite channel it’s possible to compose a polymorphic mix of IChannel<T> implementations, some blocking and some asynchronous.

ACID write

To update the Player Aggregate Root a simple Adapter writes the event to a persistent data store. This could be a relational database, a document database, a REST resource or something else – it doesn’t really matter exactly which technology is used.

public class PlayerStoreChannel : 

    IChannel<ScoreChangedEvent>

{

    private readonly IPlayerStore store;

    public PlayerStoreChannel(IPlayerStore store)

    {

        this.store = store;

    }

    public void Send(ScoreChangedEvent message)

    {

        this.store.Save(message.PlayerId, message);

    }

}

The important thing to realize is that the IPlayerStore.Save method will be a blocking method call – perhaps wrapped in a distributed transaction. This ensures that updates to the Player Aggregate Root always leave the data store in a consistent state. Either the operation succeeds or it fails during the method call itself.

This takes care of the ACID consistent write, but the application must also update the high score table.

Asynchronous write

Since eventual consistency is acceptable for the high score table, the message can be transmitted over a persistent queue to be picked up by a background process.

A generic class can server as an Adapter over an IQueue abstraction:

public class QueueChannel<T> : IChannel<T>

{

    private readonly IQueue queue;

    private readonly IMessageSerializer serializer;

    public QueueChannel(IQueue queue,

        IMessageSerializer serializer)

    {

        this.queue = queue;

        this.serializer = serializer;

    }

    public void Send(T message)

    {

        this.queue.Enqueue(

            this.serializer.Serialize(message));

    }

}

Obvously, the Enqueue method is another void method. In the case of a persistent queue, it’ll block while the message is being written to the queue, but that will tend to be a fast operation.

Composing polymorphic consistency

Now all the building blocks are available to compose both channel implementations into the GameEngine via the CompositeChannel. That might look like this:

var playerConnString = ConfigurationManager

    .ConnectionStrings["player"].ConnectionString;

var gameEngine = new GameEngine(

    new CompositeChannel<ScoreChangedEvent>(

        new PlayerStoreChannel(

            new DbPlayerStore(playerConnString)),

        new QueueChannel<ScoreChangedEvent>(

            new PersistentQueue("messageQueue"),                        

            new JsonSerializer())));

When the Send method is invoked on the channel, it’ll first invoke a blocking call that ensures ACID consistency for the Player, followed by asynchronous message passing for eventual consistency in other parts of the application.

Conclusion

Even when parts of an application must be implemented in a synchronous fashion to ensure ACID consistency, an architecture based on asynchronous message passing provides a flexible foundation that enables you to polymorphically mix both kinds of consistency in a single method call. From the perspective of the application layer, this provides a consistent and uniform architecture because all mutating actions are modeled as commands end events encapsulated in messages.

There’s this meme going around that software reuse is a fallacy. Bollocks! The reuse is a fallacy meme is a fallacy :) To be fair, I’m not claiming that everything can and should be reused, but my claim is that all code produced by Test-Driven Development (TDD) is being reused. Here’s why:

When tests are written first, they act as a kind of REPL. Tests tease out the API of the SUT, as well as its behavior. In this point in the development process, the tests serve as a feedback mechanism. Only later, when the tests and the SUT stabilize, will the tests be repurposed (dare I say ‘reused’?) as regression tests. In other words: over time, tests written during TDD have more than one role:

1. Feedback mechanism
2. Regression test

Each test plays one of these roles at a time, but not both.

While the purpose of TDD is to evolve the SUT, the process produces two types of artifacts:

1. Tests
2. Production code

Notice how the tests appear before the production code, which is an artifact of the test code.

The unit tests are the first client of the production API.

When the production code is composed into an application, that application becomes the second client, so it reuses the API. This is a very beneficial effect of TDD, and probably one of the main reasons why TDD, if done correctly, produces code of high quality.

A colleague once told me (when referring to scale-out) that the hardest step is to go from one server to two servers, and I’ve later found that principle to apply much more broadly. Generalizing from a single case to two distinct cases is often the hardest step, and it becomes much easier to generalize further from two to an arbitrary number of cases.

This explains why TDD is such an efficient process. Apart from the beneficial side effect of producing a regression test suite, it also ensures that at the time the API goes into production, it’s already being shared (or reused) between at least two distinct clients. If, at a later time, it becomes necessary to add a third client, the hard part is already done.

TDD produces reusable code because the production application reuses the API which were realized by the tests.

Now that my book about Dependency Injection is out, it’s only fitting that I also invert my own dependencies by striking out as an independent consultant/advisor. In the future I’m hoping to combine my writing and speaking efforts, as well as my open source interests, with helping out clients write better code.

If you’d like to get help with Dependency Injection or Test-Driven Development, SOLID, API design, application architecture or one of the other topics I regularly cover here on my blog, I’m available as a consultant worldwide.

When it comes to Windows Azure, I’ll be renewing my alliance with my penultimate employer Commentor, so you can also hire me as part of larger deal with Commentor.

In case you are wondering what happened to my employment with AppHarbor, I resigned from my position there because I couldn’t make it work with all the other things I also would like to do. I still think AppHarbor is a very interesting project, and I wish my former employers the best of luck with their endeavor.

This has been a message from the blog’s sponsor (myself). Soon, regular content will resume.

Greg Young gave a talk at GOTO Aarhus 2011 titled Developers have a mental disorder, which was (semi-)humorously meant, but still addressed some very real concerns about the cognitive biases of software developers as a group. While I have no intention to provide a complete resume of the talk, Greg said one thing that made me think a bit (more) about SOLID code. To paraphrase, it went something like this:

Developers have a tendency to attempt to solve specific problems with general solutions. This leads to coupling and complexity. Instead of being general, code should be specific.

This sounds correct at first glance, but once again I think that SOLID code offers a solution. Due to the Single Responsibility Principle each SOLID concrete (pardon the pun) class will tend to very specifically address a very narrow problem.

Such a class may implement one (or more) general-purpose interface(s), but the concrete type is specific.

The difference between the generality of an interface and the specificity of a concrete type becomes more and more apparent the better a code base applies the Reused Abstractions Principle. This is best done by defining an API in terms of Role Interfaces, which makes it possible to define a few core abstractions that apply very broadly, while implementations are very specific.

As an example, consider AutoFixture’s ISpecimenBuilder interface. This is a very central interface in AutoFixture (in fact, I don’t even know just how many implementations it has, and I’m currently too lazy to count them). As an API, it has proven to be very generally useful, but each concrete implementation is still very specific, like the CurrentDateTimeGenerator shown here:

public class CurrentDateTimeGenerator : ISpecimenBuilder

{

    public object Create(object request, 

        ISpecimenContext context)

    {

        if (request != typeof(DateTime))

        {

            return new NoSpecimen(request);

        }

        return DateTime.Now;

    }

}

This is, literally, the entire implementation of the class. I hope we can agree that it’s very specific.

In my opinion, SOLID is a set of principles that can help us keep an API general while each implementation is very specific.

In SOLID code all concrete types are specific.

Here’s a programming issue that comes up from time to time. A method takes a sequence of items as input, like this:

public void Route(IEnumerable<string> args)

While the signature of the method may be given, the implementation may be concerned with finding out whether there is exactly one element in the sequence. (I’d argue that this would be a violation of the Liskov Substitution Principle, but that’s another discussion.) By corollary, we might also be interested in the result sets on each side of that single element: no elements and multiple elements.

Let’s assume that we’re required to raise the appropriate event for each of these three cases.

Naïve approach in C#

A naïve implementation would be something like this:

public void Route(IEnumerable<string> args)

{

    var countCategory = args.Count();

    switch (countCategory)

    {

        case 0:

            this.RaiseNoArgument();

            return;

        case 1:

            this.RaiseSingleArgument(args.Single());

            return;

        default:

            this.RaiseMultipleArguments(args);

            return;

    }

}

However, the problem with that is that IEnumerable<string> carries no guarantee that the sequence will ever end. In fact, there’s a whole category of implementations that keep iterating forever – these are called Generators. If you pass a Generator to the above implementation, it will never return because the Count method will block forever.

Robust implementation in C#

A better solution comes from the realization that we’re only interested in knowing about which of the three categories the input matches: No elements, a single element, or multiple elements. The last case is covered if we find at least two elements. In other words, we don’t have to read more than at most two elements to figure out the category. Here’s a more robust solution:

public void Route(IEnumerable<string> args)

{

    var countCategory = args.Take(2).Count();

    switch (countCategory)

    {

        case 0:

            this.RaiseNoArgument();

            return;

        case 1:

            this.RaiseSingleArgument(args.Single());

            return;

        default:

            this.RaiseMultipleArguments(args);

            return;

    }

}

Notice the inclusion of the Take(2) method call, which is the only difference from the first attempt. This will give us at most two elements that we can then count with the Count method.

While this is better, it still annoys me that it’s necessary with a secondary LINQ call (to the Single method) to extract that single element. Not that it’s particularly inefficient, but it still feels like I’m repeating myself here.

(We could also have converted the Take(2) iterator into an array, which would have enabled us to query its Length property, as well as index into it to get the single value, but it basically amounts to the same work.)

Implementation in F#

In F# we can implement the same functionality in a much more compact manner, taking advantage of pattern matching against native F# lists:

member this.Route args =

    let atMostTwo = args |> Seq.truncate 2 |> Seq.toList

    match atMostTwo with

    | [] -> onNoArgument.Trigger(Unit.Default)

    | [arg] -> onSingleArgument.Trigger(arg)

    | _ -> onMultipleArguments.Trigger(args)

The first thing happening here is that the input is being piped through a couple of functions. The truncate method does the same thing as the Take LINQ method does, and the toList method subsequently converts that sequence of at most two elements into a native F# list.

The beautiful thing about native F# lists is that they support pattern matching, so instead of first figuring out in which category the input belongs, and then subsequently extract the data in the single element case, we can match and forward the element in a single statement.

Why is this important? I don’t know… it’s just satisfying on an aesthetic level :)

Soon after I posted my previous blog post on message dispatching without Service Location I received an email from Jeff Saunders with some great observations. Jeff has been so kind to allow me to quote his email here on the blog, so here it is:

“I enjoyed your latest blog post about message dispatching. I have to ask, though: why do we want weakly-typed messages? Why can't we just inject an appropriate IConsumer<T> into our services - they know which messages they're going to send or receive.

“A really good example of this is ISubject<T> from Rx. It implements both IObserver<T> (a message consumer) and IObservable<T> (a message producer) and the default implementation Subject<T> routes messages directly from its IObserver side to its IObservable side.

“We can use this with DI quite nicely - I have written an example in .NET Pad: http://dotnetpad.net/ViewPaste/woTkGk6_GEq3P9xTVEJYZg#c9,c26,

“The good thing about this is that we now have access to all of the standard LINQ query operators and the new ones added in Rx, so we can use a select query to map messages between layers, for instance.

“This way we get all the benefits of a weakly-typed IChannel interface, with the added advantages of strong typing for our messages and composability using Rx.

“One potential benefit of weak typing that could be raised is that we can have just a single implementation for IChannel, instead of an ISubject<T> for each message type. I don't think this is really a benefit, though, as we may want different propagation behaviour for each message type - there are other implementations of ISubject<T> that call consumers asynchronously, and we could pass any IObservable<T> or IObserver<T> into a service for testing purposes.”

These are great observations and I think that Rx holds much promise in this space. Basically you can say that in CQRS-style architectures we’re already pushing events (and commands) around, so why not build upon what the framework offers?

Even if you find the IObserver<T> interface a bit too clunky with its OnNext, OnError and OnCompleted methods compared to the strongly typed IConsumer<T> interface, the question still remains: why do we want weakly-typed messages?

We don’t, necessarily. My previous post wasn’t meant as a particular endorsement of a weakly typed messaging channel. It was more an observation that I’ve seen many variations of this IChannel interface:

public interface IChannel

{

    void Send<T>(T message);

}

The most important thing I wanted to point out was that while the generic type argument may create the illusion that this is a strongly typed method, this is all it is: an illusion. IChannel isn’t strongly typed because you can invoke the Send method with any type of message – and the code will still compile. This is no different than the mechanical distinction between a Service Locator and an Abstract Factory.

Thus, when defining a channel interface I normally prefer to make this explicit and instead model it like this:

public interface IChannel

{

    void Send(object message);

}

This achieves exactly the same and is more honest.

Still, this doesn’t really answer Jeff’s question: is this preferable to one or more strongly typed IConsumer<T> dependencies?

Any high-level application entry point that relies on a weakly typed IChannel can get by with a single IChannel dependency. This is flexible, but (just like with Service Locator), it might hide that the client may have (or (d)evolve) too many responsibilities.

If, instead, the client would rely on strongly typed dependencies it becomes much easier to see if/when it violates the Single Responsibility Principle.

In conclusion, I’d tend to prefer strongly typed Datatype Channels instead of a single weakly typed channel, but one shouldn’t underestimate the flexibility of a general-purpose channel either.