.Net

What do you think of this code?

Brian Button — Sun, 13 Jan 2008 21:15:00 GMT

I recently finished 6 weeks of coding for a client, and it was heaven! I actually got a chance to code every day, for 6 solid weeks. It was a chance for me to learn C# 3.0, and a chance to work on testing things that are hard to test. It was great!

Out of the work, came several interesting observations and coding techniques, all rooted in C# 3.0. Since no one at work has any experience with these new idioms I "invented", "discovered", or just "copied", I'd love to get some reader feedback. I'll start with this one trick I tried, and follow on with more as the mood strikes me over time.

Trick 1: Using extension methods and a marker interface in place of implementation inheritance

I had an instance of code duplication in two parallel hierarchies of classes, and I wanted to find a way to share the code. One option would be to use inheritance, factoring out another base class above BaseResponse and BaseRequest. This is where methods common to requests and responses could both live. Using inheritance as a way to reuse code in a single inheritance language is a pretty heavyweight thing to do. I'd rather find a way to use delegation, since that preserves the SRP in my class hierarchy. Instead, I decided to try an extension method, and just use that method where I needed it. To avoid polluting Object with unnecessary methods, however, I came up with the idea of using a marker interface on the classes I wanted to have these extension methods, limiting the scope where these extra methods were visible. (No idea if anyone else has done this yet or not)

For each request and response class, in the two parallel hierarchies, my client requirements made it necessary to add an XmlRoot attribute to tell the XmlSerializer that this object was the root of an XML document and to specify the runtime name of this element. To let me get the runtime name of each request and response object, for auditing and logging purposes, both hierarchies had a CommandName property, containing the exact same code. This was the code in question that I was trying to share.

As a simple exercise, I created an extension method to deal with this:

    internal static class SssMessageExtensionMethods
    {
        public static string GetCommandNameFromXmlRootAttribute(this object message)
        {
            object[] attributes = message.GetType().GetCustomAttributes(typeof(XmlRootAttribute), true);
            if (attributes.Length == 0) return message.GetType().Name;

            XmlRootAttribute xmlRootAttribute = attributes[0] as XmlRootAttribute;

            return xmlRootAttribute.ElementName;
        }
    }

This solution worked just fine, and the code ran correctly, but I still wasn't happy with my solution. The problem I was sensing was that I was adding yet another extension method to Object, and Object's neighborhood was already pretty crowded with all the Linq methods in there. I wanted my extension methods to show up only on those classes to which I wanted to apply them.

The solution that I came up with was to use a marker interface whose sole purpose is to limit the visibility of the extension methods to classes that I intend to apply them to. In this case, I made BaseRequest and BaseResponse each implement IMessageMarker, an interface with no methods. And I changed the extension method to be:

    internal static class SssMessageExtensionMethods
    {
        public static string GetCommandNameFromXmlRootAttribute(this ISssMessageMarker message)
        {
            object[] attributes = message.GetType().GetCustomAttributes(typeof(XmlRootAttribute), true);
            if (attributes.Length == 0) return message.GetType().Name;

            XmlRootAttribute xmlRootAttribute = attributes[0] as XmlRootAttribute;

            return xmlRootAttribute.ElementName;
        }
    }

Now I have the same extension method defined, but it only appears on those classes that implement the marker.

What do you think of this technique? In a more powerful language, like Ruby or C++ (ducking and running for cover!), this kind of trickery wouldn't be needed. But C# can only get you so far, so I felt this was a good tradeoff between adding the methods for needed functionality and making the most minimal change in my classes to hide these methods so that only those places that needed them could see them.

-- bab

Slides from my powershell talk

Brian Button — Wed, 31 Oct 2007 20:30:00 GMT

I gave an introduction to Powershell talk at the St. Louis .Net UG meeting on Monday, October 29th to about 70-80 people or so. I introduced basic concepts of powershell, talked about a few problems I had solved with it, and showed some simple scripts.

At the end of the presentation, I promised to post the slides by the end of this week, and I'm making it Wednesday night. Believe me when I say that me getting something finished early is a minor miracle :)

-- bab

Episode 2 - The InputReader and the start of the Processor

Brian Button — Mon, 17 Sep 2007 09:42:00 GMT

OK, so this stuff is different. Really different. So different that i feel like a TDD rookie all over again. I find myself questioning everything that I do, and wondering if I’m going in the right direction. But it’s fun learning something new…

When I last left you…

When we finished episode 1, we had created a couple of customer tests and had used Interaction Based Testing to drive out the basics of our architecture. In looking back at what we drove out, I wonder about some of those classes. I can see that I have an input side, and processing middle, and an output side, but I see an awful lot of generalization having happened already. I’m going to watch out for this throughout the rest of this exercise. It is possible that this style of writing tests drives you towards early generalization, but I’m pretty sure it is just my unfamiliarity with how to drive code through these tests that is making this happen.

The Input Side

According to the first test I wrote, this is the interface that the input side needs to have:

public interface IInputReader
{
    List<BatchInput> ReadAllInputs();
}

I don’t know anything about a BatchInput yet, or how to read the input lines, but I think I may be about to find out.

So my job now is to drive out how the IInputReader will be implemented by some class. As it turns out, this is really not very interesting. The interaction-based testing that we’ve been doing has been very useful at driving out interactions, but the InputReader seems to stand alone. It is at the very end of the call chain, which means that it doesn’t interact with anything else. This means that state-based tests will do just fine to test this piece of the system.

Here is the first test I wrote for this class:

[Test]
public void InputReaderImplementsIInputReader()
{
    Assert.IsInstanceOfType(typeof(IInputReader), new InputReader(null));
}

I’ve started writing tests like these to force me to make the class I’m writing implement a specific interface. I started doing this because I’ve found myself going along writing a class, knowing full well that it has to implement some interface, but forgetting to actually do it. I end up writing the whole class to the wrong API, and I have to go back and refactor the API to match what it should be. Hence, I write this test now to enforce me implementing the right interface.

Here are the rest of the tests:

[Test]
public void EmptyInputStreamGeneratesEmptyOutputList()
{
    StringReader reader = new StringReader(String.Empty);
    InputReader inputReader = new InputReader(reader);

    List<BatchInput> input = inputReader.ReadAllInputs();

    Assert.AreEqual(0, input.Count);
}

[Test]
public void SingleCommandInputStringGeneratesSingleElementOutputList()
{
    StringReader reader = new StringReader("a|b" + System.Environment.NewLine);
    InputReader inputReader = new InputReader(reader);

    List<BatchInput> input = inputReader.ReadAllInputs();

    Assert.AreEqual(1, input.Count);
    Assert.AreEqual("a|b", input[0].ToString());
}

[Test]
public void MultipleCommandInputStringGeneratesMultipleElementsInOutputList()
{
    StringReader reader = new StringReader("a|b" + System.Environment.NewLine + "b|c" + Environment.NewLine);
    InputReader inputReader = new InputReader(reader);

    List<BatchInput> input = inputReader.ReadAllInputs();

    Assert.AreEqual(2, input.Count);
    Assert.AreEqual("a|b", input[0].ToString());
    Assert.AreEqual("b|c", input[1].ToString());
}

These tests follow the usual 0, 1, many pattern for implementing functionality. Make sure something works for 0 elements, which fleshes out the API, then make sure it works for a single element, which puts the business logic in, and then make it work for multiple elements, which adds the looping logic. Here is the oh, so complicated code to implement these tests:

public class InputReader : IInputReader
{
    private readonly TextReader reader;

    public InputReader(TextReader reader)
    {
        this.reader = reader;
    }

    public List<BatchInput> ReadAllInputs()
    {
        List<BatchInput> inputData = new List<BatchInput>();
        ReadAllLines().ForEach(delegate(string newLine) 
            { inputData.Add(new BatchInput(newLine)); });
        return inputData;
    }

    private List<string> ReadAllLines()
    {
        List<string> inputLines = new List<string>();
        while (reader.Peek() != -1)
        {
            inputLines.Add(reader.ReadLine());
        }

        return inputLines;
    }
}

And that should pretty well handle the input side of this system.

On to the Processor

The Processor class takes the input BatchInput list and converts it into ProcessOutput objects, which are then written to the output section of the program. Here is the interface again that rules this section of code:

public interface IProcessor
{
    List<ProcessOutput> Process(List<BatchInput> inputs);
}

First of all, let’s make sure that my class is going to implement the correct interface:

[Test]
public void ProcessorImplementsIProcessor()
{
    Assert.IsInstanceOfType(typeof(IProcessor), new Processor(null, null));
}

Now, the responsibilities that seem to have to happen here are that each BatchInput object needs to be turned into something representing a payroll input line, and that new object needs to be executed in some way. Those thought processes lead me to this test:

[Test]
public void SingleBatchInputCausesStuffToHappenOnce()
{
    MockRepository mocks = new MockRepository();

    IPayrollProcessorFactory factory = mocks.CreateMock<IPayrollProcessorFactory>();
    IPayrollExecutor executor = mocks.CreateMock<IPayrollExecutor>();
    Processor processor = new Processor(factory, executor);
    PayrollCommand commonPayrollCommand = new PayrollCommand();

    List<BatchInput> batches = TestDataFactory.CreateBatchInput();

    using (mocks.Record())
    {
        Expect.Call(factory.Create(batches[0])).Return(commonPayrollCommand).Repeat.Once();
        executor.Execute(commonPayrollCommand);
        LastCall.Constraints(Is.Equal(commonPayrollCommand)).Repeat.Once();
    }

    using (mocks.Playback())
    {
        processor.Process(batches);
    }
}

There is tons of stuff to see in this test method now. Immediately after I create my MockRepository, I create my system. This consists of three objects:

IPayrollProcessorFactory — responsible for converting the BatchInput object into a PayrollCommand
IPayrollExecutor — responsible for executing the PayrollCommand after it is created
Processor — the driver of the system

Together, these three classes make up this portion of our system. If I were doing SBT (state-based testing), I’m not entirely sure at all that I would have these two embedded objects yet. I would probably have written code and then refactored to get to where I am now. But, with IBT, you have to think in terms of who the collaborators are that the method under test is going to use, and jump to having those collaborators now rather than later. In fact, the whole IPayrollExecutor seems kind of contrived at this point to me, but I need to have something there to interact with, so I can write an IBT for this.

On the next line, I create an instance of my PayrollCommand. I specifically use this instance as the returned value from the factory.Create call in the first expectation and as a constraint to the executor.Execute in the second expectation. This was something I was struggling with earlier in my experimentation with IBT. What I want to have happen is that I want to force my code to take the object that is returned from the Create call and pass it to the Execute call. By having a common object that I use in the expectations, and having the Is.Equal constraint in the second expectation, I can actually force that to happen. It took me a while to figure this out, and I’m pretty sure that this is a Rhino Mocks thing, rather than a generic IBT thing, but I found this to be helpful.

Then I drop into the record section, where I set some expectations on the objects I’m collaborating with. The first expectation says that I expect an instance of a BatchInput to be provided to this Execute method when called. Please note, and it took me a while to intellectually really grasp this, the batches[0] that I’m passing to the Create method is really just a place holder. This is the weird part here — I’m not actually calling the factory.Create method here, I’m signaling the mocking framework that this is a method I’m about to set some expectations on. I could have just as easily, in this case, passed in null in place of the argument, but I thought null didn’t communicate very clearly. What I do mean is that I expect some instance of a BatchInput to be provided to this method. Maybe I would have done better by new’ing one up in place of using batches[0]???? It is not the value or identity of the object that matters here at all, it is the type, and only because a) the compiler needs it and b) it communicates test intent. The rest of that expectation states that I’m only going to expect this method to be called once, and is allowing me to specify what object will be returned when this method is called. This last part is one of the hardest parts for me to have initially grasped. I was unsure whether this framework was asserting that the mocked method would return the value I passed it, or whether it was allowing me to set up the value that would be returned when it was called. In looking back, the second option is the only one that makes any sense at all, since these expectations are being set on methods that are 100% mocked out and have no ability to return anything without me specifying it in some way. Doh!

The second expectation is where I set up the fact that I expect the same object that was returned from the Create call to be the object passed to this call. Again, I do this through the Constraint, not through the value actually passed to the executor.Execute() method. I could just as easily passed in null there, but it wouldn’t have communicated as clearly.

Finally, I get to the playback section, call my method, and the test is over.

This is the code that I wrote to make this test pass:

public List<ProcessOutput> Process(List<BatchInput> batches)
{
    List<ProcessOutput> results = new List<ProcessOutput>();

    PayrollCommand command = factory.Create(batches[0]);
    executor.Execute(command);

    return results;
}

I know I’m not handling the results at all yet, but I’m pretty sure I can flesh out what will happen with those at some point soon.

In my second test, I’ll worry about how to handle multiple BatchInput objects. Again, this is a very common pattern for me, starting with one of something to get the logic right, and then moving on to multiple, to put in any looping logic I need. Here is the second test:

[Test]
public void MultipleBatchInputsCausesStuffToHappenMultipleTimes()
{
    MockRepository mocks = new MockRepository();

    IPayrollProcessorFactory factory = mocks.CreateMock<IPayrollProcessorFactory>();
    IPayrollExecutor executor = mocks.CreateMock<IPayrollExecutor>();
    Processor processor = new Processor(factory, executor);
    PayrollCommand commonPayrollCommand = new PayrollCommand();

    List<BatchInput> batches = TestDataFactory.CreateMultipleBatches(2);

    using (mocks.Record())
    {
        Expect.Call(factory.Create(batches[0])).
                Constraints(List.OneOf(batches)).Return(commonPayrollCommand).Repeat.Twice();
        executor.Execute(commonPayrollCommand);
        LastCall.Constraints(Is.Equal(commonPayrollCommand)).Repeat.Twice();
    }

    using (mocks.Playback())
    {
        processor.Process(batches);
    }
}

Almost all of this test is exactly the same, except I add two BatchInput objects to my list. The only other thing I need to enforce is that the object that is passed to the factory.Create method is a BatchInput object that is a member of the list I passed in, which I do with the List Constraint to the first expectation.

Here is the modified Processor code:

public List<ProcessOutput> Process(List<BatchInput> batches)
{
    List<ProcessOutput> results = new List<ProcessOutput>();

    foreach (BatchInput batch in batches)
    {
        PayrollCommand command = factory.Create(batch);
        executor.Execute(command);
    }

    return results;
}

Object Mother

In both of these tests, you’ll see a reference to TestDataFactory. This is a class whose responsibility it is to create test data for me when asked. I use it to remove irrelevant details about test data from my tests and move it someplace else. This is called the Object Mother pattern.

In the next episode…

That’s about enough for now. If any of this wasn’t clear, please let me know, and I’ll update the text to be better. In the next episode, I’ll go ahead and build the factory using SBT, since it isn’t going to interact with anything and then dive into the Processor code, which should prove interesting.

Overall, I’m pretty happy with how IBT is allowing me to focus on interactions between objects and ignore details like the contents of my domain classes entirely until I get to a class who manipulates the contents of those domain classes.

My biggest question lies in the area of premature generalization. Am I thinking too much and ignoring YAGNI? Do these tests reflect the simplest thing that can possibly work? I’m truly not sure. I tried to do better in this episode to focus on just payroll stuff and not make generic classes, like the IInputReader. I have a PayrollProcessorFactory, for example, instead of a ProcessorFactory. Those refactorings will come, and I want to wait for the code to tell me about them. IBT, I think, makes it easier to see those abstractions ahead of time, but I need to resist!

Please write with questions and comments. This continues to be an interesting journey for me, and I’m not at all sure where I’m going yet! But it is fun!

— bab

Interesting difference using nested test suites in JUnit versus NUnit

Brian Button — Mon, 10 Sep 2007 10:58:00 GMT

My friend, Jim Newkirk, introduced me to a very nice way of partitioning programmer tests for a class as you write them. Most developers write a single test class for a single application class, and just dump all tests for that class in the same place. This is not as correct as it could be (that’s Consultant-Speak for “that’s just plain wrong”).

The accepted best practice is to group together tests that have the same setup/teardown logic into the same test fixtures, which can lead to having multiple fixtures for a single class. For example, when I build a Stack class, I generally have different fixtures for each of the different states that my Stack class can have, and I put a test into the correct fixture representing its starting state. For example, I might have states corresponding to

an empty stack
stack with a single element
stack with multiple elements
stack that is full

and so on. I would create a new fixture for each of these states, and use setup and teardown to push my system into the given state for that fixture. I know that this is a departure from my previous advice about Assiduously Avoid Setup and Teardown, but I think I like where this leads me. I promise to post an example of writing tests like this over the next few days, but that example is not part of what I’m talking about here.

What I am talking about is an arrangement like this:

[TestFixture]
public class StackFixture
{
    [TestFixture]
    public class EmptyFixture
    {
        [Test]
        public void ATest() {}
    }

    [TestFixture]
    public class SingleElementFixture
    {
        [Test]
        public void AnotherTest() {}
    }
}

and so on. The main reason I like this arrangement of using nested fixtures is that it allows for me to separate out tests for different behaviors of my class into different fixtures, which lets me find them more easily and makes it easier to decide where to put new tests, and it lets me run all the tests for a particular class together at the same time. If I were to have several independent test fixtures, I would have no automated way of ensuring that I ran all of them together. The closest I could come would be to use categories, which is rather manual and error prone.

Now, what I just tried to do was to replicate this arrangement in Java, and it was harder to make it work. Using JUnit 3.8.1, I tried this:

public class StackFixture extends TestCase {
    public static class EmptyFixture extends TestCase {
        public void testATest() {}
    }
}

This gave me two tests run, one failing, so it found the test in the inner class, but found an error about no test being found in the outer fixture, StackFixture, so my tests could never all pass. I tried removing static from the class declaration, and then JUnit didn’t find the test in the inner fixture, and I still had the failure for no tests found. Clearly, not possible here.

Then I tried JUnit 4, which, like NUnit 2 and beyond, uses attributes to identify tests. In Java, they call them annotations, but they seem to be the same thing. Here is what I wrote:

public class JUnitFourFixture {
    public  class StackEmptyFixture {
        @Test
        public void EmptyAtCreation() {
            Stack stack = new Stack();

            assertTrue(stack.isEmpty());
        }
    }
}

When I ran this, I got an error popup saying that there were no tests found. Not a winner :( But when I added static to the class declaration for the inner class, things did finally work beautifully. Here is the code that worked, with an extra fixture added just to be sure, and the inner classes made static. (BTW, for those of you who don’t know, there are two kinds of inner classes in Java. Inner classes without the static prefix belong to a particular instance of the enclosing class, so when you instantiate the outer class, you’re instantiating the inner class as well, and it has access to stuff in the outer object. If you have the static prefix, then the inner class is entirely independent of the outer class, just like inner classes in C#.)

public class JUnitFourFixture {
    public static class StackEmptyFixture {
        @Test
        public void EmptyAtCreation() {
            Stack stack = new Stack();

            assertTrue(stack.isEmpty());
        }
    }

    public static class SingleElementFixture {
        @Test
        public void AnotherTest() {
            assertTrue(true);
        }
    }
}

I don’t know how many of you didn’t know this, or never had a reason to care about this, but I am teaching a Java TDD course this week. Before I taught this, I wanted to make sure it worked!

— bab

Another powershell quickie - removing all bin and obj directories beneath VS.Net projects

Brian Button — Sat, 23 Jun 2007 10:32:00 GMT

gci -recurse -include bin,obj . | ri -recurse

I was playing around with how to get this to work, and I couldn't seem to figure out why these commands didn't find the same locations to delete:

gci -recurse -include bin,obj .
ri -recurse -force -include bin,obj -whatif .

I finally got so baffled that I RTFMed remove-item, and there was my answer. In the fine print, nestled away in an example that did what I was looking for, and in the documentation for the recurse parameter was my answer...

-recurse <SwitchParameter>
Deletes the items in the specified locations and in all child items of the locations.

The Recurse parameter in this cmdlet does not work properly.

Ah ha! That's when I went to the format that I finally settled on, and everything worked.

Another blog posting mostly written to help me remember how I solved this problem the next time I encounter it!

-- bab

Asynchrony Solutions is hiring!

Brian Button — Sat, 13 Jan 2007 15:43:00 GMT

Asynchrony Solutions is looking for several developers to join our company. Our immediate requirements are:

C/C++/Unix/realtime/embedded developer — This is for an exciting, very long-term project where you would have the opportunity to write code in C, Java, and C++
Java or C#/.Net/ASP.Net developer for any one of a number of projects
Agile mentors and trainers

In addition to technical skills, agile experience is a definite plus. Even if you haven’t ever worked in an agile environment, you should be very opening to learning agile skills and working in such an environment.

I joined the company in May of this year, and I have been very happy there. I’m the VP of Engineering, and the thing that convinced me to join was the company’s committment to an agile way of thinking. There are 4 principal owners, and each of them understands, appreciates, and values agility, and this shows in how the company markets is services, how projects are run, and how people are valued. Our project teams are generally 5–10 people who work together in a warroom atmosphere. We actively encourage the agile management and development practices, and, more importantly, an agile belief system. I could go on, but it is just a great place to work. If you have questions about the company or the working environment, just let me know — I’ll be happy to answer.

For more information about our company, please see our web site. If you’d like to learn more about these opportunities, please contact me directly through this blog.

Thanks!

— bab

A Real World Example of Refactoring

Brian Button — Sun, 07 Jan 2007 12:41:00 GMT

I'm leading an agile team through developing a web site. This means that I spend most of my time managing, but on this one occasion I had the opportunity to write some code.

The problem

We had an image stored in a database that was always either 800x600 (portrait) or 600x800 (landscape). We had a need to render that image on the site either as-is or reduced to one of two other sizes. You can think of this as a thumbnail, a details image, and a full-size image. We were (of course) writing the code test first, and the tests were focusing on getting the sizes right and not so much on checking the generated images. We ended up getting it working, but we were thoroughly disgusted with the code that we produced :) At least we knew the code was bad, and resolved to fix it when we had a chance.

Before we get into the application code, let's look at the tests we wrote, and I'll explain the evolution of the code and what the classes involved are.

As you can see, the class under test is called ImageWriter. It came into being because we were being careful about resource management, so we didn't want to resize an image and expose it to the world, where it might not get disposed. So, our concept was to create this class, whose purpose in life is to write a properly sized image to a Stream. It would ensure that the image was sized correctly, it was put into the stream properly, and the resources were reclaimed. Sounds pretty simple, and it was, other than some ugly switch logic.

We wrote the first three tests you see below first, starting with just taking in the full-sized landscape image and writing that to the stream. This wasn't a hard test to get working, as you might expect. We followed that up with writing the detail-sized image, which forced us to write a conditional statement to choose between the two sizes. And then we wrote the third test, which caused us to write another else to allow us to choose thumbnail-sized images. At the fourth test, it started to get really ugly when we had to decide if the image was portrait or landscape, which added a totally different conditional statement. Very rapidly this code was becoming unwieldy. We quickly wrote the fifth and sixth tests, just to get the functionality working, since we were just following an already existing pattern, ugly though it was. Once we were finished, though, we knew we needed to refactor this beast before checking it in.

[TestFixture]
public class ImageWriterFixture
{
   private Image fullSizeLandscapeImage;
   private Image fullSizePortraitImage;
   private MemoryStream imageInStream;

   [SetUp]
   public void SetUp()
   {
       fullSizeLandscapeImage = new Bitmap(800, 600);
       fullSizePortraitImage = new Bitmap(600, 800);
       imageInStream = new MemoryStream();
   }

   [TearDown]
   public void ReleaseResources()
   {
       imageInStream.Dispose();
       fullSizeLandscapeImage.Dispose();
   }

   [Test]
   public void ImageWriteWillWriteFullSizeLandscapeImages()
   {
       ImageWriter writer = ImageWriter.GetFullSizeWriter(imageInStream);
       writer.Write(fullSizeLandscapeImage);

       Image rereadImage = ResizeImageFromStream();

       Assert.AreEqual(fullSizeLandscapeImage.Height, rereadImage.Height);
       Assert.AreEqual(fullSizeLandscapeImage.Width, rereadImage.Width);
   }

   private Image ResizeImageFromStream()
   {
       imageInStream.Seek(0, SeekOrigin.Begin);
       return Image.FromStream(imageInStream);
   }

   [Test]
   public void ImageWriterWillWriteDetailsLandscapeImages()
   {
       ImageWriter writer = ImageWriter.GetDetailsSizeWriter(imageInStream);
       writer.Write(fullSizeLandscapeImage);

       Image rereadImage = ResizeImageFromStream();

       Assert.AreEqual(306, rereadImage.Height);
       Assert.AreEqual(408, rereadImage.Width);
   }

   [Test]
   public void ImageWriterWillWriteThumbnailLandscapeImages()
   {
       ImageWriter writer = ImageWriter.GetThumbnailSizeWriter(imageInStream);
       writer.Write(fullSizeLandscapeImage);

       Image rereadImage = ResizeImageFromStream();

       Assert.AreEqual(105, rereadImage.Height);
       Assert.AreEqual(140, rereadImage.Width);
   }

   [Test]
   public void ImageWriterWillWriteFullSizePortraitImages()
   {
       ImageWriter writer = ImageWriter.GetFullSizeWriter(imageInStream);
       writer.Write(fullSizePortraitImage);

       Image rereadImage = ResizeImageFromStream();

       Assert.AreEqual(800, rereadImage.Height);
       Assert.AreEqual(600, rereadImage.Width);
   }

   [Test]
   public void ImageWriterWillWriteDetailsSizePortraitImages()
   {
       ImageWriter writer = ImageWriter.GetDetailsSizeWriter(imageInStream);
       writer.Write(fullSizePortraitImage);

       Image rereadImage = ResizeImageFromStream();

       Assert.AreEqual(306, rereadImage.Height);
       Assert.AreEqual(230, rereadImage.Width);           
   }

   [Test]
   public void ImageWriterWillWriteThumbnailSizePortraitImages()
   {
       ImageWriter writer = ImageWriter.GetThumbnailSizeWriter(imageInStream);
       writer.Write(fullSizePortraitImage);

       Image rereadImage = ResizeImageFromStream();

       Assert.AreEqual(105, rereadImage.Height);
       Assert.AreEqual(79, rereadImage.Width);
   }

}

Now here is the finished, but mostly unrefactored, source code. During the process of writing the tests, we did do some refactoring to clean up the code a bit, make things a bit more readable, etc, but we held off on the Replace Conditional with Polymorphism refactoring that we could both see coming. And that refactoring is what I want to eventually share here. So, here is our ugly code:

public class ImageWriter : IImageWriter
{
   private Stream stream;
   private readonly ImageSize desiredImageSize;
   private int desiredHeight;
   private int desiredWidth;

   private enum ImageSize
   {
       THUMBNAIL,
       DETAILS,
       FULLSIZE
   } ;

   private readonly Rectangle LandscapeFullSize = new Rectangle(0, 0, 800, 600);
   private readonly Rectangle LandscapeDetailsSize = new Rectangle(0, 0, 408, 306);
   private readonly Rectangle LandscapeThumbnailSize = new Rectangle(0, 0, 140, 105);
   private readonly Rectangle PortraitFullSize = new Rectangle(0, 0, 600, 800);
   private readonly Rectangle PortraitDetailsSize = new Rectangle(0,0, 230, 306);
   private readonly Rectangle PortraitThumbnailSize = new Rectangle(0, 0, 79, 105);

   public static ImageWriter GetFullSizeWriter(Stream imageInStream)
   {
       return new ImageWriter(imageInStream, ImageSize.FULLSIZE);
   }

   public static ImageWriter GetDetailsSizeWriter(Stream imageInStream)
   {
       return new ImageWriter(imageInStream, ImageSize.DETAILS);
   }

   public static ImageWriter GetThumbnailSizeWriter(Stream imageInStream)
   {
       return new ImageWriter(imageInStream, ImageSize.THUMBNAIL);
   }

   private ImageWriter(Stream stream, ImageSize imageSize)
   {
       this.stream = stream;
       desiredImageSize = imageSize;
   }

   public void Write(Image image)
   {
       int width = image.Width;
       int height = image.Height;

       if (width < height) // isPortrait
       {
           switch(desiredImageSize)
           {
               case ImageSize.FULLSIZE:
                   desiredHeight = PortraitFullSize.Height;
                   desiredWidth = PortraitFullSize.Width;
                   break;

               case ImageSize.DETAILS:
                   desiredHeight = PortraitDetailsSize.Height;
                   desiredWidth = PortraitDetailsSize.Width;
                   break;

               case ImageSize.THUMBNAIL:
                   desiredHeight = PortraitThumbnailSize.Height;
                   desiredWidth = PortraitThumbnailSize.Width;
                   break;
           }
       }
       else // isLandscape
       {
           switch(desiredImageSize)
           {
               case ImageSize.FULLSIZE:
                   desiredHeight = LandscapeFullSize.Height;
                   desiredWidth = LandscapeFullSize.Width;
                   break;

               case ImageSize.DETAILS:
                   desiredHeight = LandscapeDetailsSize.Height;
                   desiredWidth = LandscapeDetailsSize.Width;
                   break;

               case ImageSize.THUMBNAIL:
                   desiredHeight = LandscapeThumbnailSize.Height;
                   desiredWidth = LandscapeThumbnailSize.Width;
                   break;
           }
       }

       using (Image resized = image.GetThumbnailImage(desiredWidth, desiredHeight, null, IntPtr.Zero))
       {
           resized.Save(stream, ImageFormat.Jpeg);
       }
   }
}

The bright idea we had while we were writing it was that we would use the Rectangles to hold the dimensions of an image of the proper size, to make it easier to identify what the magic numbers for height and width meant. This also made it easier for us to write the body of each leg of the case statements. Clearly, however, this was only a short term workaround for a more proper solution later.

Beginning the refactoring

OK, so we're about to start this. I truly have never attempted the refactoring that we're going to try here on this code, so I'm going to be doing it essentially live for you. I'll try to share with you any mistakes I make, what thoughts are going through my semi-sentient head, and what I'm feeling about the code as it progresses. Our goal is to end up in a situation where any conditional behavior is moved out of a procedural if/then/else block and into some sort of polymorphic dispatch, but to do that in small, orderly steps, such that we're always pretty close to having working code.

To begin, I'm planning on opening up my refactoring book to the section on Replace Conditional with Polymorphism. As I tell my students in every TDD course I teach, please open your Fowler Refactoring books and follow the steps, as Martin makes these things easy once you figure out which refactoring to use. So, to follow my own advice, I'm going to open the book and use it as I go.

First step -- Are the responsibilities in the right place?

The first thing I notice when I look at the ImageWriter's Write method is that I see policy and details happening in the same place. The policy in that class can be summed up as, "Determine the dimensions of the final image, resize the image, and then write the image to the stream", and the details in that method are concerned with how those dimensions are determined. In order for us to do anything at all to simplify this system, we're going to have to pull the dimension calculations out into another method at least, and into another class possibly after that. So lets start with an ExtractMethod refactoring to get those dimension calculations out of there.

As my first step in doing this, I noticed that the member variables desiredHeight and desiredWidth weren't really doing anything good for me, and I could get rid of them by using height and width, the local variables declared in the Write method, in their place, as such:

public void Write(Image image)
{
   int width = image.Width;
   int height = image.Height;

   if (width < height) // isPortrait
   {
       switch(desiredImageSize)
       {
           case ImageSize.FULLSIZE:
               height = PortraitFullSize.Height;
               width = PortraitFullSize.Width;
               break;

           case ImageSize.DETAILS:
               height = PortraitDetailsSize.Height;
               width = PortraitDetailsSize.Width;
               break;

           case ImageSize.THUMBNAIL:
               height = PortraitThumbnailSize.Height;
               width = PortraitThumbnailSize.Width;
               break;
       }
   }

and so on. I think this sets me up very nicely to get rid of the individual width and height variables and replacing them with a Rectangle object. I'm going to try that in the code and see where that takes me. I'm not going to make this whole change all at once, because that's too large of a change. Instead, I'm going to find a way to refactor each leg of the switch to contain the assignment to the desiredRectangle reference and then take advantage of that rectangle to set the height and width repeatedly.

public void Write(Image image)
{
   Rectangle desiredRectangle;

   int width = image.Width;
   int height = image.Height;

   if (width < height) // isPortrait
   {
       switch(desiredImageSize)
       {
           case ImageSize.FULLSIZE:
               desiredRectangle = PortraitFullSize;
               height = desiredRectangle.Height;
               width = desiredRectangle.Width;
               break;

As you can see, I added a new Rectangle reference on line 50 which is going to hold the rectangle with the desired dimensions. And the smallest change I could make to start making use of this was to rewrite the body of the case statement starting on line 60 as you can see. For those of you new to refactoring, this is one of the most important pieces of the process -- take steps that are as small as possible. By doing this, you keep your risk down as low as possible while you're changing your code. If you take big steps and mess something up, it could take you a lot of time to get back to having something working. If you take a small step and mess something up, you can just back up a bit to where things worked. I'm taking a small step here, and just changing this leg of the switch. And after doing this, I ran my tests, and they worked. I'm going to change the rest of the legs now, running my tests between each change. I'll do this privately, as it doesn't seem very interesting to show you each step along this way.

OK, I did that, and all my tests worked, and each of the legs of the switches looks just like the sample code above, except for a different equivalent of line 60 for each case. Now that I've done this, I believe I can factor out the setting of the height and width in each leg and do that at the bottom of the method, right before actually doing the resizing. That will leave the code looking like this:

   public void Write(Image image)
   {
       Rectangle desiredRectangle = new Rectangle();

       if (image.Width < image.Height) // isPortrait
       {
           switch(desiredImageSize)
           {
               case ImageSize.FULLSIZE:
                   desiredRectangle = PortraitFullSize;
                   break;

               case ImageSize.DETAILS:
                   desiredRectangle = PortraitDetailsSize;
                   break;

               case ImageSize.THUMBNAIL:
                   desiredRectangle = PortraitThumbnailSize;
                   break;
           }
       }
       else // isLandscape
       {
          // extra stuff elided
       }

       int height = desiredRectangle.Height;
       int width = desiredRectangle.Width;

       using (Image resized = image.GetThumbnailImage(width, height, null, IntPtr.Zero))
       {
           resized.Save(stream, ImageFormat.Jpeg);
       }
   }
}

So each leg of the switches has become more simple and we're breaking out the height and width individually now only at the end. During the next refactoring, I'll probably do an Inline refactoring on height and width, as they're really not helping much, which would shrink this method down even more.

Now that we're at this point, I think I can do the ExtractMethod I talked about previously on the switch stuff and move that out into another method, so we can make the Write method only concerned with the higher level, more abstract steps of how this process works, and get the details of how the dimensions are calculated into its own method. After this refactoring, another ExtractMethod to take the mechanics of the writing to the stream out, and a couple of renamings to clarify what the rectangle dimension calculations actually mean, Write looks like this, which is just about right :)

public void Write(Image image)
{
   Rectangle imageDimensions = CalculateScaledImageDimensions(image);
   WriteScaledImage(image, imageDimensions);
}

A decision needs to be made

I'm at somewhat of a crossroads here. In looking back at the Write method, I've decided I really don't like it. Something just seems strange to me about it. I know I need to do something with scaled images, but instead I'm working with the dimensions of that scaled image. To me, the calculations of the dimensions of the scaled images and storing those dimensions into a rectangle seems like an implementation detail of how I did this. What the code really needs to be using, and written in terms of, are the scaled images themselves. In doing this, I think the method will now read better, since both lines of code in it will be using the same abstraction. Instead of using a Rectangle to represent something about the scaled image, now I can deal with the scaled image throughout the method. I like this better. This leads us to this code:

public void Write(Image image)
{
   using (Image scaledImage = GenerateScaledImage(image))
   {
       WriteScaledImage(scaledImage);
   }
}

I like this a lot better, as it seems like both of the lines of this method are dealing with the same abstraction now, a ScaledImage. This leads me to think that there is a ScaledImage class or hierarchy of classes trying to find its way out, which was our goal when we started this -- we were looking for the right place to put our polymorphic logic, and this ScaledImage class seems like the right place. The final code for this class looks like this:

public class ImageWriter : IImageWriter
{
   private Stream stream;
   private readonly ImageSize desiredImageSize;

   private enum ImageSize
   {
       THUMBNAIL,
       DETAILS,
       FULLSIZE
   } ;

   private readonly Rectangle LandscapeFullSize = new Rectangle(0, 0, 800, 600);
   private readonly Rectangle LandscapeDetailsSize = new Rectangle(0, 0, 408, 306);
   private readonly Rectangle LandscapeThumbnailSize = new Rectangle(0, 0, 140, 105);
   private readonly Rectangle PortraitFullSize = new Rectangle(0, 0, 600, 800);
   private readonly Rectangle PortraitDetailsSize = new Rectangle(0,0, 230, 306);
   private readonly Rectangle PortraitThumbnailSize = new Rectangle(0, 0, 79, 105);

   public static ImageWriter GetFullSizeWriter(Stream imageInStream)
   {
       return new ImageWriter(imageInStream, ImageSize.FULLSIZE);
   }

   public static ImageWriter GetDetailsSizeWriter(Stream imageInStream)
   {
       return new ImageWriter(imageInStream, ImageSize.DETAILS);
   }

   public static ImageWriter GetThumbnailSizeWriter(Stream imageInStream)
   {
       return new ImageWriter(imageInStream, ImageSize.THUMBNAIL);
   }

   private ImageWriter(Stream stream, ImageSize imageSize)
   {
       this.stream = stream;
       desiredImageSize = imageSize;
   }

   public void Write(Image image)
   {
       using (Image scaledImage = GenerateScaledImage(image))
       {
           WriteScaledImage(scaledImage);
       }
   }

   private void WriteScaledImage(Image scaledImage)
   {
       scaledImage.Save(stream, ImageFormat.Jpeg);
   }

   private Image GenerateScaledImage(Image image)
   {
       Rectangle imageDimensions = new Rectangle();

       if (image.Width < image.Height) // isPortrait
       {
           switch(desiredImageSize)
           {
               case ImageSize.FULLSIZE:
                   imageDimensions = PortraitFullSize;
                   break;

               case ImageSize.DETAILS:
                   imageDimensions = PortraitDetailsSize;
                   break;

               case ImageSize.THUMBNAIL:
                   imageDimensions = PortraitThumbnailSize;
                   break;
           }
       }
       else // isLandscape
       {
           switch(desiredImageSize)
           {
               case ImageSize.FULLSIZE:
                   imageDimensions = LandscapeFullSize;
                   break;

               case ImageSize.DETAILS:
                   imageDimensions = LandscapeDetailsSize;
                   break;

               case ImageSize.THUMBNAIL:
                   imageDimensions = LandscapeThumbnailSize;
                   break;
           }
       }

       return image.GetThumbnailImage(imageDimensions.Width, imageDimensions.Height, null, IntPtr.Zero);
   }
}

Next time

This entry is getting pretty long, so I'm going to end it here. When I pick it up again next time, I'll do the refactoring to pull the conditional logic out into the ScaledImage hierarchy we're going to create and see where the code takes us after that. I suspect that the WriteScaledImage method is going to find its way into there as well, given its name. One big hint that methods want to be grouped together is when you discover that they have a common abstraction as part of their name. GenerateScaledImage and WriteScaledImage seem to both be crying out to be in a ScaledImage class to me, but we'll have to see.

I'm so sorry that I haven't posted any worthwhile content in a long time, but I was tied up managing a huge waterfall-ish project all fall. That project is over, and I'm working with several different agile teams now with varying levels of involvement, which should give me more time to blog. I'm also working on 4 different proposals for Agile 2007 and one for the PMI National Congress. More on those as they get more fully formed.

As always, if you've made it this far, thanks for reading, and please let me know if you have any comments. I've had to disable comments on the blog as the spammers have taken over the comment logs, so send the emails to me directly. I'll post a summary of the best questions and my answers in my next post.

-- bab

Brian's Handy Dandy Rules of Framework Development

Brian Button — Fri, 09 Jun 2006 14:00:00 GMT

The whole basis of my talk at TechEd is that there are some non-technical rules around which creating good frameworks should revolve. Since I mined those rules from my earlier poll on this blog, I thought I should share my results with you. I give you

Brian’s Handy Dandy Rules for Framework Development

Clients come before frameworks
Ease of use trumps ease of implementation
Quality, Quality, Quality
Be an enabler
It’s a people problem

Clients come before frameworks

This was easily the most commonly heard bit of advice my poll revealed, and it matches up very nicely with my own experiences. The best frameworks are not created, they are mined out of existing code. The worst frameworks seem to have sprung from the twisted imagination of a rogue architect somewhere…

Ease of use trumps ease of implementation

As the author of a framework, you need to keep your eye on the ball of making others’ jobs easier. If you ever have to make a tradeoff between changing something to make it easier to implement and changing something to make it easier for your framework clients to use, always choose the latter. Write good documentation, ship your unit tests, and test out your APIs through writing lots of in-house client code. Lots of eyes on the API helps as well

Quality, Quality, Quality

Use Test Driven Development on your framework code, and enable framework users to use it on theirs. This means to avoid things like sealed and overzealous use of CAS. ‘Nuff said.

Be an enabler

You can’t read people’s minds, so don’t presume to know what their key uses of your framework will be. Allow people to embrace and extend your framework through extension points. Document these extension points, give lots of examples, and create automation to help users with these tasks.

It’s a people problem

Building a framework is decidedly not a difficult technical problem. We’ve built these things before, we’ll build them again. It is primarily an issue of balancing people and their conflicting interests. Good architects know this and are adept at balancing these concerns.

Summary

In a nutshell, that’s my talk. I have a lot more detail, a lot more stories, and a lot more to say. If you want to hear it, come see me Friday morning, from 9–10:30 at TechEd :)

See you there,

bab

I'll be speaking at Tech Ed!

Brian Button — Thu, 11 May 2006 15:26:00 GMT

I’ve been meaning to post this for a while, but I’m finally making myself do it now…

I’ll be giving a presentation on “Creating Your Own Enterprise Application Framework” at Tech Ed in Boston, on Friday, June 16 at 9:00 AM in Grand Ballroom A. My talk is based on experiences in my 2–1/2 years in patterns & practices and how I believe we most successfully build our libraries and frameworks. I set out to build a technical talk on this subject but quickly came to the realization that framework and library building is just as much about the softer skills of team building, politics, and negotiation.

If you’re going to be in the area, look me up!

— bab

Now playing: Rush - Force Ten