Leave the kids at home: How to decouple your projects with the Stairway Pattern
Published: 2018-09-12 12:55:45

---
title: Leave the kids at home: How to decouple your projects with the Stairway Pattern
published: true
tags: 
canonical_url: 
---

When you’re creating a new class, do you know exactly where to put it in your solution or do ya just kinda shove it near something similar and call it good?

Think about the last class you wrote – would you say it’s in its proper place? Is it _flexible_ and _easy to change_?

Aside from being developer buzzwords (and aside from the nifty strategies laid out in my [how to organize your projects](https://purple.pizza/how-to-organize-your-projects/) article), do you know what that would actually _look_ like?

Unless it’s explained to you, you can end up flying by the seat of your pants writing code a certain way _simply_ because it matches the surrounding code, but without any _real_ professional consideration.

Fortunately, as I continue my read thru the book **Adaptive Code via C#** by Gary McLean Hall, I bring more sweet tidings of pro level dev chops.

This article introduces a technique in class design known as the Stairway Pattern. It’s a pattern that will keep your code loosely coupled AND, as a side effect, will improve project organization.

It’s one of those techniques that make you feel like a responsible adult like learning how to change a flat tire.

## The Entourage Anti-Pattern

To preface the pattern, the author first explains the anti-pattern that we should avoid, known as the Entourage Anti-Pattern.

In a nutshell, the Entourage Anti-Pattern is **putting your implementations in the same project as their interfaces.**

Now, when I read this I was delighted because I’ve been doing that since the beginning of time, so I knew I was about to learn something.

The author mentions a couple reasons this can be a bad idea:

First, by having the implementation right there, a less experienced developer might come along and be tempted to use `new` and _hardcode_ the dependency into the client class, despite the interface’s existence. Take a look at [my earlier dependency injection article](https://purple.pizza/why-should-you-use-dependency-injection/) to see why hardcoding dependencies is a code-smell.

Second, and the reason it’s called the Entourage Anti-Pattern, is that clients will potentially need to bring in assemblies they don’t need.

I’ve got a great example of this in one of the applications I work on at the time of writing this. This app offers an e-signature feature that makes use of DocuSign, a very popular e-signature platform that has it’s own API for managing the entire document signing flow.

When we built this feature, we coded to an `IESignatureService` interface so that we could later swap out DocuSign for something cheaper or homegrown. Now, although we are using an interface, the `DocuSignService` implementation (which depends on a `DocuSignAPIClient` library assembly) _sits next to it in the same project_. This project also happens to be a very large one that holds _a lot_ of other business logic unrelated to e-signature.

The problem shows itself when you look at the `bin` directory of every project that makes use of that business logic project. `DocuSignAPIClient.dll` exists _in all of them!_.

That DLL is an entourage member of the business logic project, tagging along even when it’s not needed.

## The Stairway Pattern

To fix this, we apply the Stairway Pattern, which is simply keeping the implementation in a separate assembly.

Clients should only depend on an interface, which can either live in the same project as the client, or also in a separate assembly. It’s called the stairway pattern because the UML diagram showing dependencies looks… like stairs.

![UML Diagram showing the stair shape of dependencies](https://purple.pizza/public/stairway.jpg)

For our e-signature example, we could place our `DocuSignService` in a separate `ServiceImplementations` project so that its can be decoupled from the business logic project until the time that it’s needed.

But Joe, you’ll eventually have to call `new`, so the entourage will have to come along at some point, right?

Yes! If you’re using dependency injection, your implementations will be instantiated at the entry point of your application in something like an IoC container. But the benefit is that _that_ is the _only_ place `new` will be called. Giving you the ability to swap out implementations very easily.

I thought about this more while reading and found [this very useful StackOverflow response](https://stackoverflow.com/questions/29259414/stairway-pattern-implementation) from the book’s author himself. Reading it is mandatory!

## When to use it

I see this pattern coming in handy for most service classes.

One thing I’m not sure about though, is refactoring mature codebases that aren’t already built with dependency injection. Would it be better to stay consistent with the existing patterns?

Side note on consistency: I like the analogy _five books on a pile and one on the shelf is better then all six in a pile_ that I came across in [an excellent article called Livable Code](https://dev.to/jhotterbeekx/livable-code-embrace-the-practical-mess--46d6) by John Hotterbeekx. It’s an article that will help ground you in reality after all this _pristine, adaptable, clean code_ talk.

The author also mentions a common fear: that implementing this pattern could lead to large increase in the number of projects in your solution, but he doesn’t explain why that wouldn’t be the case. You’ll notice in that StackOverflow question, other folks had the same concern.

What do you think? Would you simply throw all service implementations into a single project?

I guess it depends on how many different things your application does. With the “everything but the kitchen sink” line-of-business apps I’ve worked on, implementing a pattern like this would seem daunting considering the number of features to refactor out.

On the other hand, I could start putting the metaphoric book on the shelf, and communicate to my team that this would be the new practice going forward.

If working on something quite new, I would without a doubt make this a standard practice.