In my last post, we implemented a set of interfaces in our service-classes and injected those interfaces into the Magic8BallSimulator class. This de-coupling of Magic8BallSimulator and its dependencies, allowed us to radically change how we output text in our application without breaking it. Here's the Magic8BallSimulator constructor we ended up with last time, it's nice and de-coupled:

  // snip
  // we're now injecting Interfaces, this loosens our coupling to our "injected" dependencies
  public Magic8BallSimulator(IMessageService messageService, IInputService inputService,
   IOutputService outputService) {
   _messageService = messageService;
   _inputService = inputService;
   _outputService = outputService;
  }
  // snip

Here's our previous implementation of the the SimulationRunner program (I dropped our crazy MultipleOutputService class in favor of ConsoleOutputService for the moment):

// snip
 public class SimulationRunner {
  static void Main(string[] args) {
   Magic8BallSimulator simulator = new Magic8BallSimulator(
    new MessageService(),
    new ConsoleInputService(),
    new ConsoleOutputService()
   );
   simulator.Run();
  }
 }
// snip

Wait a moment

Have a look at the SimulationRunner class above one more time. SimulationRunner is closely coupled to several specific classes, namely Magic8BallSimulator, MessageService, ConsoleInputService, and ConsoleOutputService. There's also a more subtle problem with SimulationRunner, it has more than 1 responsibility. SimulationRunner is currently:

• Setting up our application, in fact it creates a new instance of every class in the application
• Running our application (via simulator.Run())

Certainly SimulationRunner ought to have the responsibility of running our application, but how can solve our two remaining problems of:

1. Removing our application's setup responsibility from SimulationRunner, and
2. de-coupling SimulationRunner from specific instances of our service classes?

Our attack will involve using a Dependency Injection framework and a new class whose sole responsibility is setting up our application.

Autofac (https://github.com/autofac/Autofac/) - a badass Dependency Injection framework for .NET.

Here's an absurdly brief overview of what Autofac can do for us (if you want more information, check-out the above link to Autofac's google-code site or this article on CodeProject). Autofac allows us to register classes like MessageService as implementations of specific interfaces (like IMessageService). Here's the best part, if we register all our dependencies for Magic8BallSimulator as well as Magic8BallSimulator itself with Autofac, Autofac will also examine Magic8BallSimulator's constructor parameters and inject the registered dependent classes for us. That kicks ass!

Here's our new ContainerSetup class, it registers our application classes with Autofac and does our application setup work.

//snip
 public class ContainerSetup {
  private ContainerBuilder builder;

  public IContainer BuildContainer() {
   builder = new ContainerBuilder();

   // in English this reads, setup ConsoleInputService as the implementation of
   // IInputService
   builder.RegisterType().As();
   // Magic8BallSimulator doesn't implement an interface, its registered as-is
   builder.RegisterType();
   builder.RegisterType().As();
   builder.RegisterType().As();

   return builder.Build();
  }
}
//snip

Inside BuildContainer() we're registering the classes that Autofac will provide when their relevant interfaces are requested. For example, on line 10, we're registering ConsoleInputService as the class to use when one of our classes has a dependency on the IInputService interface (hey, Magic8BallSimulator depends on that interface!). Notice that we didn't map Magic8BallSimulator to anything, it doesn't implement an interface.

Problem Solved!

Here's our new SimulationRunner class. It's de-coupled from the specific classes in our application and is free of all setup responsibilities. It's asking Autofac for the class to run (that's the call to Resolve() on line 6):

//snip
 public class SimulationRunner {
  static void Main(string[] args) {
   ContainerSetup containerSetup = new ContainerSetup();
   IContainer container = containerSetup.BuildContainer();
   container.Resolve().Run();
  }
 }
//snip

As I mentioned before, since we've registered our Magic8BallSimulator class with Autofac as well as its dependencies (MessageService, ConsoleInputService, and ConsoleOutputService), Autofac will create and inject instances of those dependent classes into Magic8BallSimulator for us. Scroll up and look at the old Magic8BallSimulator constructor, it hasn't changed at all :)

For the curious

To keep this post relatively simple, I dropped our crazy MultipleOutputService class in favor of ConsoleOutputService. Remember MultipleOutputService? We used that class to show how de-coupling with interfaces allowed us to radically change a whole section of our application (and even its behavior) without breaking anything. It's also worth noting that MultipleOutputService's constructor takes a file-path string as it's argument.

If we wanted to use MultipleOutputService as our implementation of IOutputService we'd make the following change to our ContainerSetup class:

//snip
   //builder.RegisterType().As();
   string outputFilePath = Path.Combine(Path.GetTempPath(), "magic8BallOutput.txt");
   builder.Register(c => new MultipleOutputService(outputFilePath)).As();
//snip

In the code above, we're still specifying MultipleOutputService as our implementation of IOutputService, but we're also providing Autofac with a simple lambda expression to use when creating MultipleOutputService. The good news is, if we keep the code above, nothing else has to change (we'll still get radically different output behavior).

Source code for this post.

but wait, there's more

Steve asked a great question: But what if I want to use both MultipleOutputService and ConsoleOutputService? Say there is a user option to select which method to output with, can a DI framework handle this for me?

Since it's trivial to register more than one implementation of IOutputService with the dependency injection framework, the framework can still help us here. We'll have to write the user-activated output switch option though :) Here's the approach I see:

1. Remove MultipleOutputService and add PopupOutputService and FileOutputService to express our new modes of output. We'll also keep ConsoleOutputService around since one of our options is to print to the console.
   
   
2. Since this silly example currently runs in the console, I'm going to let users pass a few command-line parameters specifying how they'd like their output delivered. Legal parameter values will be: "popup","file","console", and "all". If we get odd combinations like "console all" we'll assume "all".
   
   
3. We'll also need a class to hold our configuration. That class we'll be constructed by parsing our command-line arguments and will be passed into our ContainerSetup.BuildContainer method so we'll know which classes to regsiter as implementations of IOutputService.

Here's our configuration class, aptly named Config:

//snip
 // an enumeration expressing our different output modes
 public enum OutputModes { console, popup, file, all };

 // holds our configuration, this class will be easy to expand later on
 // if we need to
 public class Config {
  public List OutputModes { get; private set; }

  public Config(List outputPreferences) {
   OutputModes = outputPreferences;
  }
 }
//snip

Here's ArgumentsParser its whole point in life is to sanity-check and parse our command-line arguments:

//snip
 public class ArgumentsParser {
  private string[] arguments;
  private string requestedOutputMode = string.Empty;

  // default output mode when no args specified
  private List outputModes = new List(){ OutputModes.console };

  public ArgumentsParser(string[] args) {
   arguments = args;
  }

  public Config GetConfig() {
   SanityCheckArgs();

   return new Config(outputModes);
  }

  private void SanityCheckArgs() {
   // no-args to check
   if (arguments.Length == 0)
    return;

   // too many args
   if (arguments.Length > 3)
    throw new ArgumentException(
     "Too many arguments were specified, expected 'console','popup','file', or 'all'");

   SetupOutputModes();
  }

  private void SetupOutputModes() {
   outputModes = new List();

   // see if each requested output-mode exists in our struct
   foreach (string outputModeRequested in arguments) {
    try {
     outputModes.Add(
      (OutputModes)Enum.Parse(typeof(OutputModes), outputModeRequested, true)
     );
    } catch {
     throw new ArgumentException(String.Format(
      "Illegal output mode '{0}' requested, expected 'console','popup','file', or 'all'",
      outputModeRequested));
    }
   }
   // handles odd input like "console all"
   if( outputModes.Contains(OutputModes.all) )
    outputModes = new List() { OutputModes.all };
  }

 }
//snip

Here are our change to ContainerSetup.BuildContainer, notice the new config parameter:

//snip
  public IContainer BuildContainer(Config config) {
   _config = config;
   // snip - previous code is still valid

   // we're now registering our IOutputService based on our pass config configuration class
   if (_config.OutputModes.Contains(OutputModes.console) || _config.OutputModes.Contains(OutputModes.all))
    builder.RegisterType().As();

   if (_config.OutputModes.Contains(OutputModes.popup) || _config.OutputModes.Contains(OutputModes.all))
    builder.RegisterType().As();

   if (_config.OutputModes.Contains(OutputModes.file) || _config.OutputModes.Contains(OutputModes.all)) {
    string outputFilePath = Path.Combine(Path.GetTempPath(), "magic8BallOutput.txt");
    builder.Register(c => new FileOutputService(outputFilePath)).As();
   }

   return builder.Build();
  }
//snip

We're now expecting a collection of IOutputService's in Magic8BallSimulator, so we'll modify that class as follows (notice the new IEnumerable constructor parameter and the _outputServices property:

//snip
  private IEnumerable _outputServices;

  // we're now injecting Interfaces, this loosens our coupling to our "injected" dependencies
  public Magic8BallSimulator(IMessageService messageService, IInputService inputService,
   IEnumerable outputServices) {
   _messageService = messageService;
   _inputService = inputService;
   _outputServices = outputServices;
  }

  public void Run() {
   PrintWelcome();
   string message = string.Empty;
   PrintInputPrompt();
   _inputService.GetInput();

   while (!_inputService.ExitWasRequested()) {
    message = _messageService.GetMessage();

    PrintMessage(message);
    PrintInputPrompt();
    _inputService.GetInput();
   }

   PrintExit();
  }

  private void PrintWelcome() {
   foreach (IOutputService outputService in _outputServices)
    outputService.PrintWelcome();
  }
  private void PrintInputPrompt() {
   foreach (IOutputService outputService in _outputServices)
    outputService.PrintInputPrompt();
  }
  private void PrintMessage(string message) {
   foreach (IOutputService outputService in _outputServices)
    outputService.PrintMessage(message);
  }
  private void PrintExit() {
   foreach (IOutputService outputService in _outputServices)
    outputService.PrintExit();
  }
//snip

And finally, here's our new SimulationRunner tying it all together:

//snip
  static void Main(string[] args) {
   ContainerSetup containerSetup = new ContainerSetup();
   IContainer container = containerSetup.BuildContainer();
   container.Resolve().Run();
  }
//snip

ThePopupOutputService and FileOutputService classes were trivial, I've added those to the new source-code for this section of the post as well.

Unit Tests up next

Although our new code is de-coupled, to ensure that its solid, we'll need to test it a bit. We'll start by testing each class separately. >> Next Post

In my last post, we finally injected dependencies into our Magic8BallSimulator class, but soon realized that by injecting specific classes with specific behaviors we were coupling Magic8BallSimulator to its dependencies. We discussed how this kind of coupling would make our application brittle for the following reasons:

1. If we want to change, say, ConsoleOutputService we risk breaking Magic8BallSimulator too, since it depends directly on ConsoleOutputService (and changing the output on the console really shouldn't break our entire application).
   
   
2. If we get a requirements change to alter how we output messages, say, to send them as Instant Messages or via Email, we'll have to rip out ConsoleOutputService and change Magic8BallSimulator as well. This makes our application less maintainable because changes to one section break and cascade to other parts of our application making the whole thing a pain in the ass to work on.

Here's the Magic8BallSimulator constructor we ended up with last time:

//snip
  public Magic8BallSimulator(MessageService messageService, ConsoleInputService ConsoleInputService,
   ConsoleOutputService ConsoleOutputService) {
   _messageService = messageService;
   _ConsoleInputService = ConsoleInputService;
   _ConsoleOutputService = ConsoleOutputService;
  }
//snip

We decided that we needed to alter Magic8BallSimulator to depend upon abstractions instead of concrete implementations, making Magic8BallSimulator loosely coupled to the classes it depends on.

Consider our ConsoleOutputService class. It's a concrete class which has a specific behavior. It prints output to the console, and it's "to the console" behavior is rather specific don't you think? This means that when we inject ConsoleOutputService into Magic8BallSimulator, Magic8BallSimulator knows not only that ConsoleOutputService outputs things, but how it outputs them as well. Now how ConsoleOutputService outputs things is its own concern, and we'd like to keep our application flexible enough so we can change how we output things without without breaking Magic8BallSimulator. The solution is simple, we need to tell Magic8BallSimulator that we have a class capable of handling output, but not how that class does its job. Here's the solution to our output problem:

Interfaces!

IOutputService - a contract to provide output functionality

//snip
 public interface IOutputService {
  void PrintExit();
  void PrintInputPrompt();
  void PrintMessage(string message);
  void PrintWelcome();
 }
//snip

This bit is important:

IOutputService is a simple contract which says "I agree to provide the following behavior (PrintExit, PrintInputPrompt etc), but how I work inside is no one else's concern. Now we only need a simple modification to ConsoleOutputService to complete our de-coupling.

ConsoleOutputService - implements IOutputService and prints to the console

//snip
 class ConsoleOutputService : IOutputService {
  //snip - this is the only change to ConsoleOutputService , really, that's it.
 }
//snip

Let's modify Magic8BallSimulator's constructor to take its new de-coupled dependency (notice we're now passing in an IOutputService interface instead of an instance of the specific ConsoleOutputService class):

//snip
  private IOutputService _outputService;

  // we're now injecting an Interface, this loosens our coupling to our "injected"
  // ConsoleOutputService dependency
  public Magic8BallSimulator(MessageService messageService, ConsoleInputService inputService,
   IOutputService outputService) {
   _messageService = messageService;
   _inputService = inputService;
   _outputService = outputService;
  }
//snip

2 more Interfaces

Let's de-couple Magic8BallSimulator from, the rest of its dependencies. Here are our remaining interfaces:

//snip
 public interface IInputService {
  bool ExitWasRequested();
  string GetInput();
 }

 public interface IMessageService {
  string GetMessage();
 }
//snip

I won't bore you with pasting copies of ConsoleInputService implementing IInputService or of MessageService implementing IMessageService (see the zip file for that code). Stay with me, things are about to get interesting.

Success!

here's our new Magic8BallSimulator class:

// snip
  // our "dependencies" are now interfaces
  private IMessageService _messageService;
  private IInputService _inputService;
  private IOutputService _outputService;

  // we're now injecting Interfaces, this loosens our coupling to our "injected" dependencies
  public Magic8BallSimulator(IMessageService messageService, IInputService inputService,
   IOutputService outputService) {
   _messageService = messageService;
   _inputService = inputService;
   _outputService = outputService;
  }
//snip

Magic8BallSimulator still has its dependencies injected, and behaves the way it did in the last post (in other words, we didn't break anything). Magic8BallSimulator still relies on the services provided by its dependent classes, but now it's de-coupled from the concrete details of how those classes do their work. Don't believe me?

Check this out

A really different implementation of IOutputService:

Yeah, that's certainly *different* :)

Here's the new implementation of IOutputService, check out PrintMessage(), it prints messages to the screen, a file, and within a Windows-forms MessageBox:

//snip
 public class MultipleOutputService : IOutputService {
  private string _outputFilePath = String.Empty;

  public MultipleOutputService(string outputFilePath) {
   _outputFilePath = outputFilePath;
  }

  private string _message = string.Empty;

  public void PrintMessage(string message) {
   _message = message;
   WriteMessageToConsole();
   WriteMessageToFile();
   ShowMessagePopup();
  }

  private void WriteMessageToConsole() {
   Console.WriteLine(_message);
  }

  private void WriteMessageToFile() {
   File.AppendAllText(_outputFilePath, _message);
  }

  // because they're not enough popups in our lives :)
  private void ShowMessagePopup() {
   MessageBox.Show(_message, "The 8-Ball says");
  }
//snip

What did we just do?

Well aside from writing a crazy output class, we've radically changed the output behavior of our application without breaking it! How? Simple. All Magic8BallSimulator knows is that it gets passed (or injected) an instance of a class which implements IOutputService, and our new (slightly odd) MultipleOutputService class does that.

Here's our new SimulationRunner class, it injects dependent classes into Magic8BallSimulator (remember, Magic8BallSimulator still sees these classes as Interfaces).

//snip
  static void Main(string[] args) {
   // output file for new output-service
   string outputFilePath = Path.Combine(Path.GetTempPath(), "magic8BallOutput.txt");

   Magic8BallSimulator simulator = new Magic8BallSimulator(
    new MessageService(),
    new ConsoleInputService(),
    new MultipleOutputService(outputFilePath) // new odd output class
   );
   simulator.Run();
  }
//snip

Source code for this post (that really is an odd output class).

In the next post

We'll have a look at a Dependency Injection framework for .NET (there are quite a few to chose from) and how it can make our lives easier. We'll also discuss the differences between running our application and starting it up to run. We'll also check out a better (and more interesting) way of wiring in our dependencies to Magic8BallSimulator. >> Next Post

In my last post (read it, its short, honestly), I created an awful Magic8BallSimulator class which violated the Single Responsibility Principle by concerning itself with:

• Message retrieval
• Reading user input
• Printing message and program output
• Handling user-interactions via a lame read-eval-print (aka REPL) loop

In this post, I'm going to:

1. Create a class per responsibility
2. Make the Magic8BallSimulator class depend on those classes
3. Inject those dependent classes into Magic8BallSimulator (you'll laugh when you see how simple this turns out to be).
4. and finally, make you sad by exposing a new problem with the code

The new classes broken out are:

MessageService - gets messages

 public class MessageService {

  public MessageService() {
   SetupMessages();
  }

  private List messages = new List();

  private void SetupMessages() {
   messages = new List() { 
    "Signs point to yes.", 
    "Yes."
    //snip
   };
  }

  public string GetMessage() {
   Random random = new Random();
   int index = random.Next(0, messages.Count - 1);

   return messages[index];
  }
 }
//snip

ConsoleInputService - reads user input from the console.

 public class ConsoleInputService {
  private string input = "input-initializer";

  public string GetInput() {
   input = Console.ReadLine();
   return input;
  }

  public bool ExitWasRequested() {
   return String.IsNullOrEmpty(input);
  }
}
//snip

ConsoleOutputService - prints output to the console.

 public class ConsoleOutputService {
  public void PrintMessage(string message) {
   Console.WriteLine(message);
   Console.WriteLine();
  }

  public void PrintWelcome() {
   Console.WriteLine("Welcome to the Magic 8 Ball simulator");
  }

  public void PrintInputPrompt() {
   Console.Write("Ask a Question, or press [Enter] to exit >> ");
  }

  public void PrintExit() {
   Console.WriteLine("Goodbye");
  }
 }
//snip

Magic8BallSimulator - Simulates a Magic 8 Ball via a lame read-eval-print (aka REPL) loop.

Oh there's a bit of Dependency Injection - MessageService, ConsoleInputService, and ConsoleOutputService are dependencies of Magic8BallSimulator, which is to say that Magic8BallSimulator cannot do its job of simulating a Magic 8 Ball without them. These dependencies are given to this class (or injected) as simple constructor parameters.

 public class Magic8BallSimulator {

  // these 3 classes are "dependencies" of this class, in that this class cannot
  // do its job without their services.
  private MessageService _messageService;
  private ConsoleInputService _inputService;
  private ConsoleOutputService _outputService;

  // here our dependencies are "injected" into this class, that's depedency injection, 
  // really that's it!
  public Magic8BallSimulator(MessageService messageService, ConsoleInputService inputService, 
   ConsoleOutputService outputService) {
   _messageService = messageService;
   _inputService = inputService;
   _outputService = outputService;
  }

  public void Run() {
   _outputService.PrintWelcome();
   string message = string.Empty;

   _outputService.PrintInputPrompt();
   _inputService.GetInput();

   while (!_inputService.ExitWasRequested()) {
    message = _messageService.GetMessage();
    _outputService.PrintMessage(message);
    _outputService.PrintInputPrompt();
    _inputService.GetInput();
   }

   _outputService.PrintExit();
  }
 }
//snip

SimulationRunner - Runs the simulator class, and injects new instances of the dependent classes into Magic8BallSimulator.

 public class SimulationRunner {
  static void Main(string[] args) {
   // watch me now, I'm injecting dependent classes
   Magic8BallSimulator simulator = new Magic8BallSimulator(
    new MessageService(),
    new ConsoleInputService(),
    new ConsoleOutputService()
   );
   simulator.Run();
  }
 }
//snip

Hmm, there's still a problem with this code

Let's have one more look at the Magic8BallSimulator constructor.

  // snip
  public Magic8BallSimulator(MessageService messageService, ConsoleInputService ConsoleInputService, 
   ConsoleOutputService ConsoleOutputService) {
   _messageService = messageService;
   _ConsoleInputService = ConsoleInputService;
   _ConsoleOutputService = ConsoleOutputService;
  }
  // snip

Notice how we're injecting instances of MessageService, ConsoleInputService, and ConsoleOutputService? What this does is, for example, couple Magic8BallSimulator to ConsoleOutputService which is a specific class printing output in a specific way (to the console). This coupling exposes us to 2 threats:

1. If we want to change, say, ConsoleOutputService we risk breaking Magic8BallSimulator too, since it depends directly on ConsoleOutputService (and changing the output on the console really shouldn't break our entire application).
   
   
2. If we get a requirements change to alter how we output messages, say, to send them as Instant Messages or via Email, we'll have to rip out ConsoleOutputService and change Magic8BallSimulator as well. This makes our application less maintainable because changes to one section break and cascade to other parts of our application making the whole thing a pain in the ass to work on.

You might be tempted to try something like the code below, don't do it.

  // snip
  public Magic8BallSimulatorEvenWorse() {
   _messageService = new MessageService();
   _inputService = new ConsoleInputService();
   _outputService = new ConsoleOutputService();
  }
  // snip

This is actually worse because it adds another responsibility to Magic8BallSimulator namely that of creating its own dependencies. This actually couples us even tighter to these dependent classes since now we're not only using their specific service-implementations, but instantiating them as well.

Luckily there's a simple way out.

We need to alter Magic8BallSimulator to depend upon abstractions instead of concrete implementations, making Magic8BallSimulator loosely coupled to the classes it depends on.

(Awfully coupled) source code for this post, witness the bad design first hand!

We'll explore this way out in the next post

Consider this simple Magic 8-Ball Simulator class, here's the UI:



and here is the code, reading it should take perhaps a minute.  Heck just read the Run() method.

 public class Magic8BallSimulator {

  public Magic8BallSimulator() {
   SetupMessages();
  }

  public void Run() {
   PrintWelcome();

   PrintInputPrompt();
   GetInput();

   while (!ExitWasRequested()) {
    GetMessage();
    PrintMessage();
    PrintInputPrompt();
    GetInput();
   }

   PrintExit();
  }

  private List messages = new List();

  private void SetupMessages() {
   messages = new List() { 
    "Signs point to yes.", 
    "Yes."
    //snip
   };
  }

  private string message = String.Empty;

  private void GetMessage() {
   Random random = new Random();
   int index = random.Next(0, messages.Count - 1);

   message = messages[index];
  }

  private void PrintMessage() {
   Console.WriteLine(message);
   Console.WriteLine();
  }

  private void PrintInputPrompt() {
   Console.Write("Ask a Question, or press [Enter] to exit >> ");
  }

  private string input = "place-holder input";

  private void GetInput() {
   input = Console.ReadLine();
  }

  private void PrintWelcome() {
   Console.WriteLine("Welcome to the Magic 8 Ball simulator");
  }

  private void PrintExit() {
   Console.WriteLine("Goodbye");
  }

  private bool ExitWasRequested() {
   return String.IsNullOrEmpty(input);
  }
 }

Why does this class suck?

Simple, it is doing way too much work.  As our requirements change and we work on this class, we'll start to introduce bugs in unexpected places.

[Requirements Change]: We'd like to store the 8-ball messages in a flat-file database.

Can you honestly do that without the risk of breaking unrelated code like message output?  Imagine the following scenario:

You: "Yeah, so I was making changes to how the messages are stored and fetched and I broke the way they print to the screen."
Your teammates: "Hmm, OK". sheesh this guy cannot work on one feature without breaking something completely unrelated

Hey those two responsibilities are not related! So put them in different classes. In fact the code above has lots of responsibilities:

• Message retrieval
• Reading user input
• Printing message and program output
• Handling user-interactions via a lame read-eval-print (aka REPL) loop

Separate responsibilities, separate classes, separate reasons for changing code. This is the Single-Responsibility Principle, a grand and simple assertion that: There should never be more than one reason for a class to change.  In my experience, most programmers dismiss this principle as obvious, and yet cannot seem to follow it when programming.  In fact this kind of code is present in project's which I've otherwise been damn proud to work on.

Source code for this post, please only download it to shun it, and never speak of it again.

Let's fix this code

In the next post we'll see what breaking this class up entails.