jaybaz [MS] WebLog : Refactoring

Thoughts on bit fields.

jaybaz_MS — Tue, 11 Jan 2005 17:09:00 GMT

In C there is a long tradition of using bit fields to store a collection of boolean values:

enum

{

TF_KEYWORD = 0x0001,

TF_MEMBER = 0x0002,

TF_IDENTIFIER = 0x0004,

TF_STRINGLITERAL = 0x0008,

TF_CHARACTERLITERAL = 0x0010,

} TOKENFLAGS;

DWORD dwTokenFlags = TF_KEYWORD | TF_MEMBER;

This tradition has been carried over to C#, which is my area of interest. The support for bit fields in C# is a little different than C++, but my opinion of them hasn’t changed.

Upsides:

Potetential performance improvements due to reduced memory consumption. If 'bool' takes 8 bits, and a bit flag takes one, the 8:1 memory saves could concievably have a significant effect on performance. Of course, without real measurements you don't really know.

Downsides:

They're hard to define correctly. For each value, I have to write a definition that gives it a single, unique bit. If I forget that I'm writing in hex, I get a difficult to diagnose bug.

[Flags]

enum TokenFlags

{

Keyword = 0x0000,

Member = 0x0001,

Identifier = 0x0002,

StringLiteral = 0x0004,

CharacterLiteral = 0x0008,

VerbatimStringLiteral = 0x0016,

}

Did you notice that two of these items are broken?

It's hard to add new ones. If I want to insert a new value in the middle, I have to renumber all the remaining items.

In the debugger it's hard to know what the values are.

The code to manipulate them is hard to write correctly and hard to read.

// this means "if either one is set"

if (dwTokenFlags & (TF_CHARACTERLITERAL | TF_IDENTIFIER))

// this means "if both are set"

if (dwTokenFlags & (TF_CHARACTERLITERAL | TF_IDENTIFIER) == (TF_CHARACTERLITERAL | TF_IDENTIFIER))

// unset this flag

dwTokenFlags &= ~TF_CHARACTERLITERAL;

If there are rules about which flag combinations are legal, it's hard to enforce.

You can't add a constructor to initalize the flags to a default.

You can't add useful methods for checking aggregate combinations of flags.

It's tempting to add unrelated flags in the same enum, and then hard to split them out later.

It's tempting to use a single bit for multiple meanings in different contexts.

enum NODEFLAGS

{

// Only valid when the node is a MODIFIERNODE

NF_MOD_ABSTRACT = 0x0001,

NF_MOD_NEW = 0x0002,

NF_MOD_OVERRIDE = 0x0004,

NF_MOD_PRIVATE = 0x0008,

NF_MOD_PROTECTED = 0x0010,

NF_MOD_INTERNAL = 0x0020,

NF_MOD_PUBLIC = 0x0040,

// Only valid when the node is a STATEMENTNODE

NF_UNCHECKED = 0x0001,

NF_GOTO_CASE = 0x0002,

NF_TRY_CATCH = 0x0004,

NF_TRY_FINALLY = 0x0008,

NF_CONST_DECL = 0x0010,

};

If you get more than 32 of them, you’re out of luck. We have a case in our code today with 31 distinct values. We’re worried that we may need to add 2 soon…. Yikes!

It’s easy to mix up two types of flags:

// Type flags

DWORD dwFlags = TF_CLASS | TF_PUBLIC;

// Member flags

DWORD dwMember = MF_METHOD | MF_PRIVATE;

if (dwMember | TF_PUBLIC) // OOPS!

Potential for improved performance due to better memory alignment. Every time you access a bit flag, you have to execute multiple CPU instructions. 'bool' takes fewer instructions. This also means your code is smaller. Of course, without real measurements you don't really know.

A simple alternative: a class containing public 'bool' fields.

class TokenFlags

{

public bool Keyword;

public bool Member;

public bool Identifier;

public bool StringLiteral;

public bool Characterliteral;

}

TokenFlags tf = ...;

if (tf.Characterliteral || tf.Identifier)

This is easy to write and easy to understand. It solves most of the problems I listed above.

A hybrid approach: Encapsulated bit fields.

Hey, this is 2005, I should think about encapsulation. If I do some performance analysis & find that my application is too slow because of memory consumed by bools in Flags types that look like the one I showed above, it’s easy to convert:

class TokenFlags

{

enum Indexes

{

Keyword,

Member,

Identifier,

StringLiteral,

Characterliteral,

}

BitArray _bits = new BitArray(Enum.GetValues(Indexes).Length);

public bool Keyword

{

get { return this._bits[Indexes.Keyword]; }

set { this._bits[Indexes.Keyword] = value; }

}

public bool Member

{

get { return this._bits[Indexes.Member]; }

set { this._bits[Indexes.Member] = value; }

}

public bool Identifier

{

get { return this._bits[Indexes.Identifier]; }

set { this._bits[Indexes.Identifier] = value; }

}

public bool StringLiteral

{

get { return this._bits[Indexes.StringLiteral]; }

set { this._bits[Indexes.StringLiteral] = value; }

}

public bool Characterliteral

{

get { return this._bits[Indexes.Characterliteral]; }

set { this._bits[Indexes.Characterliteral] = value; }

}

Notice that this is source compatible with the ‘public bool’ approach, except if you pass one of the members with ‘ref’. If you’re worried about that, or binary compatibility, then use properties instead of public fields. But you know how I am about properties.

What about OO?

Good question. It’s taken me this far to consider OO.

It depends on the nature of the problem domain that you’re trying to work in, but there is surely an OO way, right?

For example, suppose we did:

interface IToken { }

interface KeywordToken : IToken { }

interface MemberToken : IToken { }

interface IdentifierToken : IToken { }

interface StringLiteralToken : IToken { }

interface CharacterLiteralToken : IToken { }

Well, I can write:

IToken token = ...;

if (token is KeywordToken)

F();

But now I can start taking code that was on the clients of the flags, and move it on to the tokens.

Before:

if (token is KeywordToken)

{

FooForKeyword()

}

else

{

FooForOthers()

}

After:

interface IToken

{

void Foo();

}

token.Foo();

Refactoring the C# Express Starter Kit – Part 2: Organizing fields

jaybaz_MS — Sun, 22 Aug 2004 05:18:00 GMT

Looking in RssView, I see a big mess. There are lots of fields. Some are related to each other & different from others, which suggest an Extract Class.

Some are set at initialization time, while others change over time. Clearly there’s a difference there, but it’s not called out in the code.

All the initialize-time fields are set via public properties after the object is created, but should be set via the constructor. As it is, there’s a risk of not setting a required property, or of a property changing value later when that’s a bad idea. Also, it’s valuable to mark fields ‘readonly’ when possible. There seems to be a split between “identity” and “state” fields. I want to explore the value of putting all the initialize-time fields in a helper class, and all the state fields in another. I want to see what happens when I do that. Also, I’m thinking of Ron Jeffries suggestion that fields should all change at the same rate.

Since most of the fields are initialize-time, I’m going to start there first.

I take all the fields that look like init-time, and wrap them in a nested class:

public class Configuration_

{

// Where to draw

public Rectangle Location;

//...

}

Configuration_ configuration = new Configuration_();

public Configuration_ Configuration { get { return this.Configuration; } }

I have the underscore because otherwise there would be a conflict between the name of the property and the name of the type. I hope to eventually figure out a better way to name these things, without the underscore, but I don’t want my inability to think of a good name to stop my Refactoring fun.

Next I go to all the references to those fields and add “Configuration.”:

this.Configuration.rssChannel = rssChannel;

I run, and it immediately crashes. The ‘Configuration’ property has an infinite recursion. This is a common coding error, at least when I’m doing the coding. If I was pairing, maybe my pair would have noticed. If I had a unit test, maybe it would have caught this sooner. If I was following my naming convention of prefixing private fields with an underscore, maybe I would have caught this sooner. If the compiler would warn on this, that would be nice.

Luckily it’s easy to fix. I run again, and things seem to be working.

I see that the top of the screen has a white box across it. I can’t remember if that’s supposed to be there or not. I should go back to the original version of the sources & see what happens there, but I’m feeling lazy and/or rushed.

Oh yeah, I should make the ‘configuration’ field readonly, since I can.

The last thing I want to do before I go is to get rid of the properties & use public readonly fields. You already know that I don’t like trivial properties. I get the same syntax at 1/3 the code.

Search/replace and rectangle select are pretty useful for this, but I wish the IDE would make it easier on me.

In the process I discover an issue with the code. The max & min items to show are set in two places. They have a default initialized value, and a passed-in value. I think that Refactoring to use the readonly fields pattern has helped make this issue more visible.

I’m not sure who should own the value; for the time being, I’ll make them ‘const’ instead of ‘readonly’ and let the RssView own them.

The Configuration_ class now looks like this:

public class Configuration_

{

// Where to draw

public readonly Rectangle Location;

//...

public Configuration_(Rectangle location, RssChannel rssChannel, Color backcolor, Color bordercolor, Color forecolor, Color titlebackcolor, Color titleforecolor, Color selectedforecolor, Color selectedbackcolor)

{

this.Location = location;

//...

}

The construction of the RssView now looks like:

RssView.Configuration_ config = new RssView.Configuration_(

new Rectangle(new Point(2 * Size.Width / 20, 3 * Size.Height / 20), new Size(10 * Size.Width / 20, 12 * Size.Height / 20)),

//...

);

// Initialize the two classes that draw the RSS contents

// Use the first channel of the RSS feed

rssView = new RssView(config);

Now the RssView only has 5 fields; we’re making some kind of progress.

I’d like to refactor all those ‘Color’ values. There seem to be relationships between them. I imagine that a class that represents a foreground/background color pair would be valuable.

I’m also confused by that huge expression that selects the location of the RssView. What does it all mean? Why does it multiply by 2 & divide by 20? Is that different than dividing by 10? If I can figure out what it’s trying to do, maybe I can find a clearer way of expressing it.

In general, I think that having data (the color values) in my code is a bad idea. It makes unit testing more complicated. It makes seeing the logic in the code harder, because the data is intermingled. It makes changing the data harder, because I might accidentally change the behavior while I’m at it. I tried to push some of the data into resources, but I got stuck pretty quickly. I have to admit, managed resources are pretty confusing to me. Refactoring this stays on the TODO list, and learning about resources goes there, too.

IDisposable … or not

Commenters on the last post noted that I may not be disposing Pen and Brush objects. Turns out the situation is pretty bad.

In the BorderedRectangle, it’s easy:

using (Pen pen = new Pen(this._color, this._thickness))

{

g.DrawRectangle(pen, this._rectangle);

}

But in RssItemView it’s not. There is a Pen field that isn’t disposed. It’s also replaced by the set_LineColor and set_LineWidth, which means you could potentially leak a whole lot of handles pretty quickly.

There’s not an easy way to just toss in ‘using’ at this point and make the problem go away. I am going to leave the bug in place because I’m still working on cleaning up RssView at this point. When I turn my attention to RssItemView, I’ll probably refactor it in such a way that this bug will be trivial to fix.

One commenter also suggested renaming Location to Bounds, which I’ve done. Seems reasonable.

In a discussion with Cyrus, he gave me a hard time for creating types with an underscore suffix. He’s completely justified, but I haven’t found a solution I like better. If we come across something better, I’ll apply it.

Some good feedback on the Range post.

jaybaz_MS — Fri, 20 Aug 2004 17:06:00 GMT

Dithermaster says “it's *much* easier to find out of they DON'T overlap” and proposes:

! ( (end2 < start1) || (start2 > end1) );

If we apply DeMorgan’s Law, we get:

(! (end2 < start1) && !(start2 > end1) );

And

(end2 >= start1) && (start2 <= end1);

Right? Even simpler. However, this idea disappears in my new code, as I do comparisons on the whole ranges, as suggested by Thomas Eyde:

Overlap(a, b){

return IsInside(a) || IsInside(b);

}

IsInside(a) {

return IsBetween(a, this.a, this.b) || IsBetween(a, this.b, this.a);

}

IsBetween(c, a, b) {

return a <= c && c <= b;

}

They bring different kinds of simplicity to the problem.

James Manning is the first to notice the bugs in my unit tests which allow bugs in my code to get by. Those are now fixed.

Mikeb notices that out-of-order parameters to the range can get you into trouble. I’m not sure which way to go on this. I decided that you’d be surprised that:

new Range(s, e).Start != s

so I went with the exception.

I thought pretty hard about whether Ranges should be constrained to IComparable types. I can’t think of any cases of ranges of non-ordered items, but I don’t want to make the constraint if I don’t have to. However, adding the constraint makes my code a bit simpler. In the end, I decided to take the constraint, solving the 99% case.

I also thought hard about whether ‘Overlaps’ should be a method on Range. It’s clear that ‘Contains’ should be, but I’m not sure where to put a method that acts on two peers. In the end, I decided to put the logic on an instance, and leave the static class for convenience of callers.

One thing I find myself desparately wishing for is operator constraints on generics. Then I could use ‘<’ and friends, instead of:

return this.Start.CompareTo(other) <= 0 && this.End.CompareTo(other) >= 0;

Luckily I only have to compare in 3 places.

The logic does seem to be much simpler now & easier to read. I’m happy about that.

Here’s the code:

class Range<T> where T : IComparable<T>

{

public readonly T Start;

public readonly T End;

// static void Swap<U>(ref U left, ref U right)

// {

// U u = left;

// left = right;

// right = u;

// }

public Range(T start, T end)

{

if (start.CompareTo(end) > 0)

{

throw new ArgumentException("Arguments are out of order");

// you may decide to just allow this & reorder, but I'm

// not sure that's a good idea.

//Swap(ref start, ref end);

}

this.Start = start;

this.End = end;

}

public bool Contains(T other)

{

return this.Start.CompareTo(other) <= 0 && this.End.CompareTo(other) >= 0;

}

public bool Overlaps(Range<T> that)

{

return this.Contains(that.Start) || this.Contains(that.End);

}

static class Range

{

public static bool Overlap<T>(Range<T> left, Range<T> right)

where T : IComparable<T>

{

return left.Overlaps(right);

}

And the revised tests:

Range<int> r = new Range<int>(1, 3);

Debug.Assert(r.Contains(2));

Debug.Assert(!r.Contains(5));

Debug.Assert(Range.Overlap(

new Range<DateTime>(new DateTime(1), new DateTime(2)),

new Range<DateTime>(new DateTime(1), new DateTime(2))

));

Debug.Assert(Range.Overlap(

new Range<DateTime>(new DateTime(1), new DateTime(3)),

new Range<DateTime>(new DateTime(2), new DateTime(4))

));

Debug.Assert(Range.Overlap(

new Range<DateTime>(new DateTime(2), new DateTime(4)),

new Range<DateTime>(new DateTime(1), new DateTime(3))

));

Debug.Assert(!Range.Overlap(

new Range<DateTime>(new DateTime(3), new DateTime(4)),

new Range<DateTime>(new DateTime(1), new DateTime(2))

));

Debug.Assert(!Range.Overlap(

new Range<DateTime>(new DateTime(1), new DateTime(2)),

new Range<DateTime>(new DateTime(3), new DateTime(4))

));

}

Thanks for all your ideas. J

Refactoring the C# Express Starter Kit

jaybaz_MS — Thu, 19 Aug 2004 22:17:00 GMT

Yesterday I decided to take a look at the code we shipping in the Beta 1 C# Express SKU for a screen saver. I was pretty disappointed in the quality of the code, so I decided to refactor.

I’ve talked about some ideas about coding styles here on this blog, and I wanted to explore some of those ideas in this real context.

Most of my attention has been focused on the class “RssView”. 174 lines of text, 20 private fields, 13 trivial get/set properties, and only 7 methods.

Choosing a Rectangle

Let’s pick something to attack. This pair of fields are a little smelly:

// Where to draw

private Point location;

private Size size;

This notion seems familiar to me. Hmm, I think I would call it a Rectangle. So, replace it:

Rectangle location;

And start fixing up references. When I came across this reference, I had to hold my nose:

private void DrawBackground(Graphics g)

{

g.FillRectangle(new SolidBrush(BackColor), new Rectangle(Location.X + 4, Location.Y + 4, Size.Width - 8, Size.Height - 8));

g.DrawRectangle(new Pen(BorderColor, 4), new Rectangle(Location, Size));

}

What is this about? It’s trying to draw a filled, bordered rectangle. The border is 4 pixels wide. Why does it hard code the values of ‘4’ and ‘8’? Let’s make a note of this method & refactor it later.

DrawBackground

Now it’s later.

I see that Rectangle has an ‘Inflate’ method. Pushes out all 4 sides of a rectangle in exactly the way you see here. So switch to something like:

Rectangle fillRectangle = location;

fillRectangle.Inflate (-4, -4);

g.FillRectangle (new SolidBrush(BackColor), fillRectange);

The fact that we switched from Point/Size to Rectangle is what made Inflate available to us. Depending on your point of view, either:

This is proof that Rectangle really is the right way to go, and that getting the types right in your system will always make your code clearer, cleaner, and simpler.
We just got lucky, finding exactly the method we needed.

Maybe it’s the second one, but I sure seem to get lucky a lot!

BorderedRectangle

I pondered this method more, and decided that the notion of a rectangle with a border, which could draw itself, was a basic notion that I’d like to see as its own class. So I wrote one.

class BorderedRectangle

{

public class Colors

{

public readonly Color Fill;

public readonly Color Border;

public Colors(Color fill, Color border)

{

this.Fill = fill;

this.Border = border;

}

readonly int _fillBorderThickness;

readonly Rectangle _location;

readonly Colors _colors;

public BorderedRectangle(Rectangle location, Colors colors, int fillBorderThickness)

{

this._location = location;

this._colors = colors;

this._fillBorderThickness = fillBorderThickness;

}

public void Draw(Graphics g)

{

DrawInnerFill(g);

DrawBorder(g);

}

void DrawBorder(Graphics g)

{

Pen pen = new Pen(this._colors.Border, this._fillBorderThickness);

g.DrawRectangle(pen, this._location);

}

void DrawInnerFill(Graphics g)

{

Brush brush = new SolidBrush(this._colors.Fill);

Rectangle innerRectangle = this._location;

innerRectangle.Inflate(-this._fillBorderThickness, -this._fillBorderThickness);

g.FillRectangle(brush, innerRectangle);

}

There’s now a lot more lines of text to represent this simple notion. However, each line is much simpler; most of them are trivial. If there are bugs in this code, they should be easy to work out.

My first implementation had a “Color fillColor” and “Color borderColor”. I decided that these are related, so I grouped them into a new type. I think that nested types are critical to this kind of Refactoring. First, I avoid cluttering the namespace with a bunch of new tiny classes. Second, it’s clear what the relationship is between BorderedRectangle and BorderedRectangle.Classes. Finally, I can give simple names to my simple classes.

There’s a pattern here that I find myself writing a lot. A class with a series of ‘readonly’ fields, and a single public constructor that takes a parameter for each & assigns it to the field. BorderedRectangle.Colors is an example of this pattern. For lack of a better name, I’ll call it an “Entity Class”. I write it so much that I wish for a feature in the editor to help me do it. I suspect it’s a code smell, but I don’t yet see a Refactoring. Let’s keep it in mind.

I think I’m done for now, but I notice have 2 private methods, which is apparently a code smell. How would I refactor that? I think I would create a class called “Border” and a class called “Fill” and give them “Draw” methods. Maybe I’ll do that next time.

There’s still a lot of code smells in the start kit. Hopefully the pace will pick up soon.

Also, I’m working without a pair & without unit tests. I’m a little worried about that. This code wasn’t built TDD, so retrofitting tests is hard. Maybe I’ll be OK, because just running the app lets you verify it quickly. Let’s see if I get in to trouble later.

Making “Promote Local” make sense.

jaybaz_MS — Fri, 30 Jul 2004 02:50:00 GMT

We’re sitting around watching a video from a usability study.

A subject has been exploring the Refactoring menu, and has just tried Promote Local. With the help of the very specific error messages I wrote (yay exceptions), he finally gets it work.

On the audio track you hear him thinking out loud, describing what just happened – how the code was just transformed. Then he goes quiet. 4 full seconds of complete silence.

“Oh, WOW”.

“That… Now I understand the value in that; that’s a HUGE time saver”

And goes on to talk about how it’s a great productivity boost.

The video was sent under the heading “A feel-good video clip for you”, with the comment “This is what we would like to see as the standard user experience for new releases”.

Sure, it sounds good to hear someone say they like one of our features so much. But it also makes re-enforces my concern that Promote Local isn’t discoverable. Most people will look at the menu item, wonder for a moment what it means to “promote” a local, and then move on. The name doesn’t seem to resonate with most users.

The problem seems to be made worse by the fact that Promote Local has no option for Preview Changes. That’s mainly because there’s no UI that could offer that option; the feature is very streamlined. If you’re feeling inquisitive enough to try to run the Refactoring, you won’t get the expressive feedback from Preview about how it changes your code.

We’ve been brainstorming a bit about how to rectify the situation.

Perhaps we should rename the feature (and menu item).

The feature is meant to fill the Add Parameter space, so maybe we should call it that. Of course, you’d be pretty surprised to have Add Parameter fail because the cursor isn’t on an initialized local variable.

We could do “Add Parameter from Local Variable” or “Add Local Variable as Parameter” or something. Those names seem a bit clumsy, but maybe they’ll do the trick. If you’ve read Fowler, you’ll probably expect to find an Add Parameter Refactoring.

One thing we probably should have done is made the menu items dynamic, inserting symbol names in them. So “Rename…” becomes “Rename Foo…”. Thinking along those lines, we could do “Promote Local Variable ‘foo’ to Parameter” “Promote Local Variable ‘foo’ to Parameter of ‘F()’” or “Make Local Variable ‘foo’ a Parameter of ‘F()’”.

One option suggested by a reader is to link to my sig change blog from a tool tip. <wink>

I’m going to see if I can help the documentation folks get really good docs for Promote Local into the product. At least that way, if you do go looking at help you’ll figure it out. But I don’t expect most people will do that.

I need your help. How can I make it clear what Promote Local is? What would you like to see in the product?

Whidbey Refactorings: Signature Change

jaybaz_MS — Sun, 25 Jul 2004 22:51:00 GMT

Almost 4 months after the first post in the series… not bad!

There are 3 Signature Change Refactorings:

Remove Parameter
Reorder Parameter
Promote Local

I rank these as “Tier 2” – they’re not as important as Extract Method and Rename, but they’re still pretty hard to do by hand. They also have some complexity that can’t be resolved easily, making them slightly less reliable than the Tier 1 Refactorings.

The first attempt

Our first attempt created one feature called Signature Change. There was a single menu item & a single piece of UI. You were to invoke them on a method in your code, showing a form you could interact with. There you would party on the signature for a while, then commit all your changes.

This approach is very Microsoft – build a full-featured tool that doesn’t just enable a scenario, but covers every contingency we can anticipate. Think “one stop shopping”. The form had a lot of buttons & stuff. It was huge.

It was also wrong.

It didn’t match the Elvis attribute of being “code focused”. That is, we think that the C# customer is more comfortable manipulating code in an editor than in a form. (Contrast with Mort, who prefers forms to code.) This is the same reason we removed things like “Add Method” in the class view.

Once you were in this UI, it was only natural to expect it do even more, like rename the method or a parameter. This continued to add to the complexity of the UI & hurt usability.

It also didn’t match the way people really manipulate method signatures. You don’t look at a method and say “this method has 5 things wrong with its signature, and now I’m going to fix them”. You’re more likely to say “this method needs a new parameter for the work I plan to do” or “this method works correctly, but doesn’t match my coding convention of having all ‘out’ params at the end of the argument list”. That is, sig. change Refactorings are always small single steps and the UI we built was optimized for big steps (really multiple small steps).

As you can see, all this added up to it being the wrong UI, at least for Elvis (the typical C# customer). It was a very typical Microsoft way of building a feature, so it took us a little time to get on the right track.

As a special case of the “code focused” bit, it really worked poorly for “Add Parameter”. You click on the button and get a small dialog with 3 fields (name, type, default value). You then get to a fully qualified type name into an edit field. That’s no fun, especially since typing in the editor gets you a familiar, well-tuned IntelliSense experience. Finally, the name “default value” was confusing, because it seemed to suggest C# language support for default parameter values like those that exist in C++ and VB.

The second try

So, we took the UI and tore it apart. In the editor you can now click on a method (at the call site or definition) and request a Remove Parameters or Reorder Parameters.

Reorder Parameters

A form appears allowing you to move parameters up & down on a list. Once they’re to your liking, you can apply the change.

This isn’t quite the ideal, code-focused model I would have liked. You’re acting on the whole method’s parameter list, but I think that acting on single parameters might have been better. Instead of being able to arbitrarily reorder all the parameters on a method at once, suppose we just supplied “move right” and “move left” operations on each parameter individually? Suppose they were extremely fast. That would probably be a simpler, more streamlined experience, and be more Code Focused.

Remove Parameters

Similar UI to Reorder, you can “delete” one or more parameters from the list.

Similar to my concerns about Reorder, I think that a model focused on removing a single parameter would be a better experience than this model, which allows you to remove multiple parameters at once.

Remove carries a small risk of changing the behavior of your code. Consider:

F(i++);

Removing the parameter will change the behavior of your code. We considered building more smarts protect against this, and then decided not to solve the halting problem for Whidbey. Instead, we put a warning on the UI that this Refactoring could change the behavior of your code. You can use the “Preview Changes” option if you’re worried. (Personally I avoid coding styles that allow this problem, by differentiating between “query” and “action” methods, but we still need to make sure that we’re building tools for our customers, not for ourselves.)

Similar issues are possible in the Reorder case, but even less common, so we decided not to clutter the UI with a warning in that case.

Invocation Model

For both Reorder and Remove, you can invoke them via the context menu or the top-level Refactor menu, at either a call site or the definition. This brings up a modal form to manipulate the selected method.

You can also invoke these 2 Refactorings using “smart tags”. We put one on the definition of each method in your code, as a way of indicating “there are special things you can do here”. For both Refactorings, the smart tag offers Reorder and Remove actions.

Aside: Users seem mildly annoyed by smart tags in Office usability studies. If they had a more positive reaction there, you would have seem more aggressive use of smart tags in VS. For example, we could place a smart tag on every definition, of fields, locals, parameters, types, methods, etc. Most would offer at least rename, and each might offer other cool stuff. For example, the smart tag on a parameter might also offer the “Move Left” and “Move Right” actions I mentioned previously.

Smart tags are a lot like context menus, but even more focused on the location & should provide greatly added value, compared to the context menu & other sources of actions.

They seem to solve a certain class of discoverability & clutter issues. For example, suppose we decided to put “Move Left” & “Move Right” on the context menu. If we only show them in the menu when you click on a parameter, then users will see it once without realizing what the context was, and then get frustrated trying to find it again. If we always show it on the context menu, no matter where you click, then the context menu quickly becomes cluttered.

These are the things we spend our days fretting over!

Add Paramters

Where’s “Add Parameter” in all this? Well, it’s not in Whidbey. I was convinced that there wasn’t a good user model for providing this Refactoring, at least with the facilities we had available at the time.

The problem is that no one wants to type type names into dialogs. It’s just no fun. Completion lists are where it’s at. (We talked about showing a completion list on the dialog, but morphing the code to support that seemed pretty expensive. I’m also not convinced that it would be an ideal experience.)

There was also this really odd bit where you had to supply a default value to pass in at all existing call sites. I already mentioned that the name “default value” was confusing because that name already refers to something in C++ and VB. It also caused problems because typing in the default value in an edit box isn’t ideal, either, like the type name. If you’re going to pass anything other than a simple constant, you really want to have IntelliSense helping you out. (Imagine passing “new SomeType(param1, param2)” – you’d want parameter help on that constructor, right?)

Really, the notion of typing this stuff in to a form just doesn’t fit with the code-focused nature of the typical C# customer.

We decided to just cut the feature for Whidbey, and come back to it later.

Promote Local

Then we came up with a cheap alternative that seemed to add a lot of value. Suppose you have a method with this line of code in it:

bool b = true;

Notice that it has exactly the right data for “Add Parameters” – name, type, value. We could build a Refactoring that would take an initialized local variable & “promote” it to a parameter. The type & name of the new parameter are exactly that of the local variable. The value to pass in at all the call sites is the value on the left of the equals. You got to write the type & the value using your favorite tool for the job (the C# editor, of course!).

What I’m talking about doesn’t solve all “Add Parameter” needs in the way we would have liked. It wasn’t clear that users who were looking for a way to add a parameter would think of trying this, and we wondered if users would just be plain confused by the whole idea. We also looked at the schedule and saw that there wasn’t much time to fit something like this in, especially if it wasn’t going to be the “ideal” solution.

We decided to take the cheapest approach possible. If people don’t like the feature, it wouldn’t be a big loss. It would fit in without causing the schedule to slip. So we first applied a set of constraints:

The value on the right must be a constant. This way we know it can be passed in legally at all call sites.
The value on the left can’t even be a constant expression (“1 + 1”), because analyzing that sort of thing could be hard.
The variable must be initialized at creation time. So reject “int i; i = 1;”.
The new parameter goes at the front of the parameter list.
No options. There’s just one way to do it, and that’s it.

Looking back, I’m really glad things worked out this way. It’s very XP-like. We took the smallest step that delivered the greatest value to our customer. If we did this more of the time, we would ship a lot more often!

As XP-ers know, building working software generates a lot of learning. As soon as we started exploring Promote Local, we saw that it needed a bit more flexibility to really be useful, so we changed the constraints somewhat:

If the value on the right isn’t obviously a constant, we’ll warn that it may not be the right thing to pass in at all call sites, but still allow it. For example, if the value includes a local variable, things aren’t likely to turn out well.

This allows some really important cases, like “Foo f = new Foo(“hi”);”. Note that we don’t fix up any type names on the right side. We just take the text in your code, as typed, and copy it to all call sites. It’s the simplest approach I could think of!

In the normal Microsoft way of thinking, we might have decided to build up a lot of logic to decide if the thing on the right was acceptable for the call sites. We could analyze visibility of any methods called, and offer to change their accessibility. We could offer to Encapsulate Field any fields that might be needed at the call site. We could fully qualify type names on the right, or offer to add ‘using’ directives as needed. But that would have been too expensive to deliver in Whidbey (we would have had to cut something clearly more important), so instead we would have cut Promote Local. But, applying more of the thinking we’ve learned from XP, we decided to continue to deliver this simple, cheap Promote Local.

I’ve heard people ask that we be smart about placing the parameter in the correct location (before all ‘out’, ‘ref’, and ‘params’ parameters), or offer UI that lets the user select the position of the new parameter. I argue that you’d rather accept the default of first position, and then later apply Reorder Parameters if you want to change things. This lets you take a smaller step & get back to delivering customer value sooner. (To be fair, there are many who disagree with me on this point.)

Promote Local is the only Refactoring we built that doesn’t have a form to take input. That means there isn’t a good place to put an option to Preview Changes. I get requests that we do something about this, but I really like the streamlined behavior we have today. Click on a local variable, invoke the command, and you’re done. That’s it. (Obviously, there are many who disagree with me on this point, too.)

Aside: Earlier I mentioned what we might have done with more smart tags. If we put a smart tag on all local variable definitions, one of the items on it would be “Promote to Parameter”.

Two other things about Promote Local are important to me:

It’s written in C#. Most of the Whidbey C# IDE is written in C++. (Extract Interface and the various forms for other Refactorings are the other exceptions.)
I wrote it. I spend a lot of my time managing people (oh, and blogging), so any code I get to ship is pretty special to me.

What else?

Missing from the picture are the “ret <-> out” Refactorings.

The first takes a method with no return type (“void”) and changes one of its ‘out’ parameters to be the return type.

void F(out int x) //...

F(out x);

Becomes

int F() //...

x = F();

Seems pretty cool, but there was a lot of complexity to overcome.

The second is the inverse (takes a return value and makes it an “out” parameter). This one is even harder to do, because sometimes the return value is the input to another method:

G(F()); // how do we do ret->out on F?

These would have been nice to have when you use Extract Method; it removes the question of how to decide what to do with outputs from the new method (“all ‘out’ params? Select one to be return and others be ‘out’?”).

However, the value of these Refactorings is lower than a lot of other very cool stuff, and the costs were pretty high due to the complexity involved. So they didn’t make it in Whidbey.

In the case of all of these Signature Change Refactorings, it’s clear we could have done a bit more work to make them even cooler. But as I mentioned in the beginning, these are “Tier 2”, so we would rather spend less time on them in favor of our Tier 1 Refactorings.

Thoughts?

So, what do you think? Did we get it right? Will these Refactorings, as written, suit your needs?

Should we have stuck with the single form for all? Or continued pushing in the small steps direction? If we provided both models, which would you use?

Is Promote Local interesting and valuable as-is, or just a waste of time & UI space?

Do you need the ret<->out params more than we realized? Would you rather we cut something else in their favor?

For Beta 2, should we punt a set of bugs to make time to enhance these Refactorings?

If you want to discuss, comment here. If you have stronger feedback, then send it via Ladybug.

Answer Ron's questions about C# Refactorings.

jaybaz_MS — Sun, 25 Jul 2004 19:19:00 GMT

On the Yahoo! Groups Refactoring DL, Ron Jeffries asked some questions about Visual C# 2005 Refactorings.

"Can you say how you expect the Microsoft refactorings to stack up against the existing ones that are out there?"

I've personally spent very little time exploring the C# and Java Refactoring tools out there. Most of what I know is from the competitive analysis efforts of the PMs on the team, and what I read on this group. I keep meaning to get some first-hand experience with them, but never find the time. (Too busy reading Ron's book!)

The most obvious difference will be that the Refactoring menu in Visual Studio will be quite a bit shorter than the others. We decided to focus on making a smaller set of higher quality Refactorings.

The other big difference is that our Refactorings are very good at giving you reliably correct results. It is our goal that when applied to a legal C# program, you can be sure that your code will maintain its behavior.

The build on this laptop has 7 Refactorings:

Rename
Extract method

These two are by far the most important that we built. They rank very high on “difficulty to do by hand” and “value to your code”.

Reorder parameters
Remove parameters
Promote Local Variable to parameter

These three together are “change method signature”. These aren’t nearly as important for your code as Rename & Extract Method, but they can be quite hard to do by hand. Note that Add Parameter is missing. Promote Local takes its place, providing a more code-focused experience.

Encapsulate Field

This was easy to build on top of the technology that provides Rename, and it leverages C#’s properties so we can say we’re cooler than that other language. You can get by without it in a few steps including a Rename, so it doesn’t rank so well on the “hard to do by hand” scale.

Extract Interface

As we read through the Fowler list, this one seemed simple to do, so we did it. However, it’s not something you need to use very often, so I’m not sure I’d choose if I had to do it over. Perhaps I would have selected a streamlined Push Up Method instead, which could fill the same needs and others.

One of the themes we picked up on part-way through is that there’s value in building smaller, simpler Refactorings, and letting users compose them at will.

We can build them with a simpler UI. Instead of a bunch of options, you get to select which Refactorings to apply when. For example, Promote Local doesn’t provide any flexibility about where in the list to insert the new parameter; it always inserts at the start of the list. We expect that you’ll use Reorder Parameters to get the results you want.

“Is there any plan to make refactoring support pluggable, or otherwise to improve the ability of normal humans to generate code?”

We don’t intend to build Refactoring extensibility into this product. Bummer, huh? I hope we can get to it soon, though; it's clearly important.

One of the features we did build is “Generate Method Stub”, where we will take a call to a method that doesn’t exist & generate a stub that matches. It’s great for TDD & Programming by Intention.

Refactoring the XMLNotepad

jaybaz_MS — Tue, 20 Jul 2004 22:14:00 GMT

I’ve been reading Extreme Programming Adventures in C#. Currently reading Chapter 28 (Undo).

Through most of the book, there has been a bit of Refactoring that the code has been crying out for. At first I thought Ron was waiting to until the duplication got worse, thereby justifying the Refactoring as providing real customer value.

I finally downloaded the final sources from the MSPress site, and see that the smells are still there. So I did the Refactorings myself, and found that the code is much improved for it.

Duplication between SkipTags and Insert Tags:

private static InsertAction[] insertActions = new InsertAction[] {

new InsertAction(

Tags.Pre,

"Insert &Pre",

new string[] { "<pre></pre>" }, // <------ here

new string[] { "<pre>" }), // <------ here

I changed it to take an array of tags:

new string[] { "pre" }),

And figure out the insert & skip text later:

public string[] TagsToInsert

{

get

{

List<string> list = new List<string>();

list.AddRange(TagsToSkip);

List<string> reversed = new List<string>(tags); reversed.Reverse();

foreach (string s in reversed)

{

list.Add("</" + s + ">");

}

return list.ToArray();

}

public string[] TagsToSkip

{

get

{

List<string> list = new List<string>();

foreach (string s in tags)

{

list.Add("<" + s + ">");

}

return list.ToArray();

}

This is not, strictly speaking, a Refactoring. The original code could insert tags on the same line, and my code always puts new tags on new lines. I should probably talk to my customer to understand how important this is to them. If it is important, I’d need to do enough additional work that the Refactoring might be too expensive and should be abandoned.

Still, I like the effect on the code, so I’m going to try to get my customer to go along.

Note: I’m cheating by using C# 2.0 features like List<>. Ron didn’t have them when writing his book.

Duplication around the ‘Tags’ enum

There’s a lot of it. There’s a bunch mapping back and forth between the enum & the InsertAction command. I decided to make them the same:

public static class InsertActions

{

public static InsertAction Pre = new InsertAction(

"Insert &Pre",

new string[] { "pre" }

);

public static InsertAction Section = new InsertAction(

"Insert &Section",

new string[] { "sect1", "title" }

);

public static InsertAction UnorderedList = new InsertAction(

"Insert &UL",

new string[] { "UL", "LI" }

);

public static InsertAction OrderedList = new InsertAction(

"Insert &OL",

new string[] { "OL", "LI" }

);

public static InsertAction Paragraph = new InsertAction(

null,

new string[] { "P" }

);

public static InsertAction ListItem = new InsertAction(

null,

new string[] { "LI" }

);

// it's important that all new InsertActions be added to this list, or they

// won't get handled correctly. That means there's a little duplication still,

// but it's very much localized now. Yay OO.

public static InsertAction[] All

{

get

{

return new InsertAction[] {

Pre,

Section,

UnorderedList,

OrderedList,

Paragraph,

ListItem

};

}

A lot of the associated changes are quite simple:

public void Enter()

{

if (InListItem())

InsertTags(InsertActions.ListItem);

else

InsertTags(InsertActions.Paragraph);

}

We also get rid of a bit of code. SectionCommand() is replaced with InsertActions.Section, which is a huge win in removing duplication.

public InsertAction SectionCommand() {

foreach (InsertAction a in InsertActions) {

if (a.MenuString == "Insert &Section" ) return a;

}

return null;

}

And InsertActionForCommand is gone:

private InsertAction ActionForCommand(Tags command) {

foreach ( InsertAction action in InsertActions) {

if (action.Command == command)

return action;

}

return null;

}

Now that it’s done, now how much simpler the creation of InsertAction is.

Before

new InsertAction(

Tags.Pre,

"Insert &Pre",

new string[] { "<pre></pre>" }, // <------ here

new string[] { "<pre>" }), // <------ here

After

public static InsertAction Pre = new InsertAction(

"Insert &Pre",

new string[] { "pre" }

);

I think this is a real improvement.

The hidden costs of a Refactoring

jaybaz_MS — Wed, 07 Jul 2004 17:49:00 GMT

Looking over our oldest C++ code, there is, of course, a lot of potential for Refactoring. That’s a nice way of saying that it sucks.

We learned about Refactoring because we wanted to build good tools for our customers. Along the way, we also realized that we wanted to Refactor, too. One of the benefits of working on a development tool is that you get to spend a lot of time thinking about how you develop.

Normally when I think about the challenge of doing an Extract Method, I think about things like:

Figuring out the inputs & outputs, and their types
Making sure that the block I’m extracting has consistent exit rules
Thinking up a good name for the new method

With a little thinking, some more costs appear:

· In C++, the method signature must exist in both the .h and .cpp files. They’re almost, but not quite, identical.

· If I didn’t get the signature right the first time, I have to fix it in both places.

· I need to check both the .h and .cpp files out of source control.

As I start to dig in, I find even more work to do:

My class has too many methods to manage. I could break out a new class in the same file, but then:
My file has too many classes. I could break out a new file, but then

I need to add the new .cpp file to source control, the .vcproj, and my build system.
I need to add the .h in the same way
I need to include the .h in the right places
I have too many files in the directory/project

Now I need to create a new project, a new subdirectory to hold it, and move files around in the build system & in source control

So today I have too many files in each directory; too many classes in each file; too many methods in each class; too many statements in each method. I’d like to refactor more, but I have to start at the other end – working on the build system & file system.

On my team we’ve focused most of our attention on what appears to be the “hard part” – getting the signature of the extracted method just right. The rest is stuff we’re sure you can do without help. But the truth is that all that resistance backs up & you won’t refactor mercilessly.

Integration helps. If you use VSS (ouch!) or otherwise have your source control integrated with your C# project, then Whidbey Refactorings will check out the files automatically. And if you use the same project file for nightly builds & IntelliSense, then you can skip a step. Still, the cost is there.

Rename and Extract Method are the two most important Refactorings we could provide. But before we go further, maybe we should stop and think about the integration story. Make sure that you can get your whole project arranged well with as little effort as possible. Imagine if creating a new class in a new project took 0 effort. Would you refactor more?

Refactoring Party

jaybaz_MS — Thu, 01 Jul 2004 19:24:00 GMT

In What are my Goals?, Jim asked:

How do you plan to "Develop a culture of energy, productivity, and learning on the team"?

One of the activities I have in mind is a reoccurring Refactoring Party. It works like this:

Each week we come together for an hour to practice Refactoring. You bring a piece of code & we will refactor it as a group. The code can be:

Something you came across that’s so bad you want to show us so we can have a good chuckle. After we clear the milk from our noses, we’ll get serious & refactor it, making the code as clean as possible.
Something you came across that’s so bad you don’t even know where to begin. We’ll start refactoring & see how clean we can get it.
A piece of code you wrote that you’re really proud of, because it’s so clear. You want to show it off to us, so we can appreciate your genius. We’ll burst your bubble by pointing out ways to make it better. <evil grin>

There are couple things I hope to get out of it:

Practice of the actual act of Refactoring. It’s a skill, and practice is important.

Shared learning about selecting Refactorings. Deciding where to go with the code can be challenging, and everyone may have a different answer; we can learn by sharing these ideas.

Exposure to the ideal can change your thinking. Seeing the result of the refactoring effort can inspire you to think in new ways about just what “clear code” really means.

Language Readability vs. Writability

jaybaz_MS — Thu, 01 Jul 2004 18:57:00 GMT

In my previous post, I said:

“Unfortunately, language readability is often at odds with writability.”

And

“Generic method type parameters are inferred from the concrete parameters”

Here’s what I’m talking about:

T F<T>(T t) { return t; }

void Test()

{

Console.WriteLine(F(1) + 2);

}

Which overload of Console.WriteLine gets called?

The compiler sees that you’re passing ‘1’ to F(), which is an int. So, the concrete parameter ‘t’ is an int, so the type parameter ‘T’ is an int, so F() returns an int. Add an int to ‘2’ and you get an int. So, we are calling

public static void WriteLine(int value);

I don’t think that’s immediately obvious from the code, but it sure is easier to write than:

Console.WriteLine(F<int>(1) + 2);

The other inference added in C# 2.0 is with delegates. Consider:

delegate void D();

void F() { }

void Test()

{

D d = F;

d();

}

It’s certainly easier to write than:

D d = new D(F);

But because it’s inferred, it’s harder to read, both for tools & for devs.

The final point was about ‘foreach’. Today you write:

void Test(List<int> myList)

{

foreach (int i in myList) { }

}

But why not let you write:

void Test(List<int> myList)

{

foreach (i in myList) { }

}

Can’t the compiler figure out the type of ‘i' for you? Yes, but now you’ve compromised readability:

foreach (i in foo.bar(baz(x))) { }

Now, to know the type of ‘i', you have to correctly figure out which overload of ‘bar’ is called, which requires figuring out the correct overload of ‘baz’, too. It could be quite complicated.

Since I’m on the editor team, I think solution lies in an editor. When making a decision about read vs. write, one option is to select easy-to-read, and then use the editor to make it easy to write. For example, a smart editor could infer & insert the type in the ‘foreach’ for you automatically.

Hmm, guess I need to get to work!

Language design for Refactoring

jaybaz_MS — Thu, 01 Jul 2004 18:39:00 GMT

A question came up on the Yahoo! Groups Refactoring Group about what language design would be best to support Refactoring.

We think about this quite a bit, but usually we phrase the question more generally:

What language design would make it easiest to write tools that work well?

That includes Refactoring, as well as Intellisense, Syntax Coloring, etc.

The answer seems to be that explicitness: a language that forces the developer to be explicit, instead of implicitly inferring stuff from the context.

It seems like this is really the answer to:

What language design makes the code easy to read?

Unfortunately, language readability is often at odds with writability. This is a point that language designers struggle with all the time.

In C# 2.0, there are two points of inference that were added to the language:

Generic method type parameters are inferred from the concrete parameters.
Anonymous method type is inferred from the usage

We discussed, but did not add inference of the type of the instance variable in a ‘foreach’ statement.

There’s an MSDN Magazine article that discusses some of these points in C# 2.0.

In general, the design of C# has focused on making your code more explicit that C++, to avoid many of the pitfalls we observed in C++. That same explicitness has made C# Refactoring easier to get right.

No private methods

jaybaz_MS — Sat, 12 Jun 2004 00:54:00 GMT

I’m heading off into the deep end here. If you want to come with me, make sure you’re wearing your SCUBA gear.

One of the first questions that come up in TDD with NUnit is “How do I test private methods?” Usually the answer looks like “Don’t do that, because XXX”, like:

· If your class has interesting private functionality that you’re inclined to test, that functionality might be interesting to a consumer of your class. Expose it. In this way, TDD is an exercise in Domain-Driven Design, where the domain is software writing, and the user is you in a few minutes.

· It’s a code smell. If your class is so complex that you need to test private methods, you should refactor to pull some of that complexity into its own class.

There are other reasons, I’m sure. If you have one, comment on it…

So I had this crazy idea. What happens if you take the second bullet to the logical extreme? What if you continue performing Extract Class until there are no more private methods? Private fields are fine, but only public methods.

It’s an idea. I don’t know if it’s a good idea or a bad idea. Even if it’s a good idea, I don’t know if I can do it well. So if I try it and the result sucks, I don’t know if it’s because the idea is bad or just because I can’t do it right.

I can try to imagine what might happen if you try this.

Obviously, you’d have a lot of small classes. You’d need to be careful to ensure that they made sense.

I think you would end up with deep nesting of classes, with built-in types at the very bottom, like:

class C

{

int i;

public void F() { }

}

class D

{

C c;

public void G() { }

}

class E

{

D d;

public void H() { }

}

How does this jive with Object Thinking’s suggestion that you shouldn’t end up with a large number of classes? (I think it does jive, but I need to think about it more.)

Is the result really easy to unit test? I hope so, but is it?

Is the code ultra-readable or a total mess?

Is refactoring this code impossible or trivial?

If you get good at this, does it change your thinking about the ideal size of a class? (The balance between many simple classes and few internally complex ones?)

I need to find a good programming problem & try this out.

Your expectations of Refactoring.

jaybaz_MS — Sat, 05 Jun 2004 02:00:00 GMT

Your expectations of Refactoring.

Cyrus posts about what you expect from Refactoring. The particular issue he’s dealing with is Extract Method when the result will pass a generic argument to a method.

He offers these three choices:

Don’t add ‘ref’, potentially changing code behavior in a very subtle way.
Always add ‘ref’, which may be unnecessary spam for you.
Prompt the user to choose.

If we add an option, it will be on this UI:

I’m really wary of adding this as an option. The default answer to every dialog box is "Cancel". Users don’t want another option to think about. Most of the time, they will just accept the default & move on.

In this case, the amount of brain energy required to understand the problem and make a decision is very high. It’ll be pretty unusual for someone to make an educated decision about this bit of UI.

Now let’s look at the cost of making the wrong choice:

If we don’t add ‘ref’ & you are passing a mutable value type & mutate it in the new method, you get a very subtle bug. You have to discover the bug through some testing, analyze to find the cause, and fix it.
If we add ‘ref’ and you know you don’t need it, you remove the word ‘ref’ from two locations in your code & continue about your day.

I really hope you aren’t using mutable value types in your code. (In fact, once you’re done reading this blog, go review all your structs and make sure they’re immutable.) However, if you are mutating value types, you’d really hate it if we broke you!

I vote for option #2 because it’s safer. What do you want to see? Go to Cyrus’s blog & say.

Note: this page has much cleaner HTML than usual.

enum->class Refactoring the OO way

jaybaz_MS — Mon, 31 May 2004 17:18:00 GMT

This one was pretty much TheoY’s. I coded it up, which probably means I corrupted his idea. So, give him credit for the good parts and I’ll take balme for the bad parts.

Pretty much the same approach was taken in C++ by Johny in his comment.

abstract class E

{

private E() { }

public abstract void OperationF();

public class _a : E { public override void OperationF() { } }

public static readonly _a a = new _a();

public class _b : E { public override void OperationF() { } }

public static readonly _b b = new _b();

public class _c : E { public override void OperationF() { } }

public static readonly _c c = new _c();

}

class Program

{

void F(E e)

{

E e2 = E.a;

e.OperationF();

if (e == E.a)

{

return;

}

So, by making them into singletons, we lose the ability to switch() on the value. But that’s actually a good thing – we’re doing one of the “ReplaceTypeCode” Refactorings from Fowler.

Are there any other interesting solutions, or is this pretty much it?