I was recently invited to attend the Chicago Software Craftsmanship presentation on “Untangling the Gilded Rose”. While I was unfortunately unable to attend, I found the topic inspirational enough to write about. The topic was a code kata, described as taking an existing code base and refactoring it to be more maintainable. The kata for this blog post is called the Gilded Rose Kata and is described here with a project template found here.
1. Write the Specs
We are given the specs, but I’ve copied and consolidated them below. They seem simple at first, but going through them multiple times reveals some subtleties.
- ‘Aged Brie’ increases quality increase by 1 each day.
- ‘+5 Dexterity Vest’ quality increase by 1 each day.
- ‘Elixir of the Mongoose’ quality increase by 1 each day.
- ‘Sulfuras, Hand of Ragnaros’ quality and sellin stay the same.
- ‘Backstage passes to a TAFKAL80ETC concert’ quality goes up by 1 each day when the Sellin is greater than 10. Quality increases by 2 when there are 10 days or less and by 3 when there are 5 days or less but Quality drops to 0 after the concert.
- “Conjured” items degrade in Quality twice as fast as normal items.
- All items quality is never negative.
- All items quality may never go over 50.
Do we understand the specs? In this case, a few things weren’t clear from the specs.
- Would the item being updated ever be in an invalid state? If so, how would we handle it? I’m going to assume no for the purposes of the refactoring since neither the original code nor the specs address this issue.
- Should the Quality being calculated before or after the SellIn is reduced? We can derive this from the current code base, which indicate we should reduce the sellin before calculating the quality.
- Should we consider if multiple rules could apply to an item? For example, what if there was a “Conjured Aged Brie” that required both the rules for “Conjured” and “Aged Brie” be applied? We’ll assume no, as there no indication from the specs this should be considered.
- There are many other possible requirements that we’ll ignore and assume should be up to our discretion since they are not explicitly stated, e.g. performance, development methodology, testing methodology, etc.
2. Write the tests
One of the purposes of the Kata is to practice TDD, or test driven development. So we’ll first write our unit tests. However, this leads to a common chicken or egg problem with TDD. How do I know what classes and methods to test when there is no class design yet? Typically, I will think through the overall class design and write the stubs before writing the units test, so at least there is a starting point. There will be probably be changes and not all of our assumptions may turn out to be true, but its better to plot a course now and adjust later than to completely miss the mark.
3. What are the design goals?
The kata is pretty open ended as far as design goals. Given this, we’ll come up with our own set of goals to accomplish.
- Localize item processing to the item’s type – The low cohesion of the items type to the calculation for that type’s quality is probably the most serious problem we see with the current design. If you were trying to follow how the quality was calculated for “Backstage passes to a TAFKAL80ETC concert” it would be difficult as it is in 2 different places, separated by unrelated code, and deeply nested within if/else structures. We want to have a single place for each items quality calculation.
- Reduce nested if/else structures. Nested if/else constructs make code difficult to understand. Why? Because you have to understand several different lines of code in conjunction to understand if a particular nested statement will be executed. Favor flattening conditional statements whenever possible. This will localize the conditional logic of whether a particular statement is executed.
- Make testable – We want all of our code to be easily testable with unit tests so any further refactoring will be easier and have code coverage.
4. The design
So the design I went with is to have a class for each unique update algorithm. This is going to be represented by a strategy pattern. This will allow us to iterate through each item and apply the update function to each item independently of knowing the type of each item. This leaves us with a mapping problem of finding the correct strategy for the type. We will solve this with a factory pattern to create and return the strategy instance for the unique type.
public interface IUpdateStrategyFactory
{
IUpdateStrategy Create(string name);
}
public interface IUpdateStrategy
{
void UpdateQuality(Item item);
}
5. Write the code
I won’t go through all the trivial details, but here is the factory, 2 of the strategies, and the greatly simplifed UpdateQuality() loop.
public class UpdateStrategyFactory : IUpdateStrategyFactory
{
public IUpdateStrategy Create(string name)
{
if (name == "Sulfuras, Hand of Ragnaros")
{
return new DoNothingUpdate();
}
else if (name == "Aged Brie")
{
return new AgedBrieUpdateStrategy();
}
else if (name == "Backstage passes to a TAFKAL80ETC concert")
{
return new BackstagePassesUpdateStrategy();
}
else if (name.Contains("Conjured"))
{
return new ConjuredUpdateStrategy();
}
else
{
return new StandardUpdateStrategy();
}
}
}
public class StandardUpdateStrategy : IUpdateStrategy
{
public void UpdateQuality(Item item)
{
item.SellIn--;
if (item.Quality <= 0)
{
return;
}
else if (item.Quality == 1)
{
item.Quality = 0;
}
else
{
item.Quality -= item.SellIn < 0 ? 2 : 1;
}
}
}
The final loop is now much easier to read and understand.
public void UpdateQuality()
{
foreach (Item item in Items)
{
var updateStrategy = _strategyFactory.Create(item.Name);
updateStrategy.UpdateQuality(item);
}
}
That’s it! If you have any feedback, please leave it below in the comments. The source code is available for download.
Update: I’ve added my solution to github. https://github.com/jacerhea/GildedRose
The Code Nose 