One of the big reasons I’ve found myself preferring C# Over Java is that C# is about a million times easier to refactor. By this, I mean that often times you can make rather large changes to a codebase without changing very much other code. This is possible because C# has features such as Properties (which allow you to encapsulate logic on what appears to be a variable access), operator overloads, and casting overloads (though those sort of count towards the previous point). Java doesn’t have these features, so I’ve found changes to the core logic of a program can cause reverberations throughout the entire codebase as every piece of logic that referred to the previous structure is made to refer to the new stuff. If you suddenly decide that a field needs logic, you need to create an Accessor method for it, and then you need to change all the references to the aforementioned field. This is easiest to accomplish by renaming the original field name so your compiler errors point to where you used it and changing each of those. C#, in contrast, let’s you change a field into a Property with very little impact on the code within that codebase. it does, of course, have the effect of requiring any dependent assemblies be recompiled and naturally any reflection that uses the aforementioned field will need to instead look for a property, but it will require very little actual code changes.

In a Previous post I discussed and provided a class that allowed the relatively transparent replacement of core fields in a class definition with a generic type that made the in-memory representation of that type obfuscated. This allowed a lot of logic to be executed transparently from code that used to simply access the field. Naturally this did have performance implications, but the fact that it’s possible to make such class definitions and their uses transparent aside from changing the declaration is one of my favourite features of C#. Combine this with the fact that changing, modifying, and refactoring existing code comprises a large portion of our work as developers and you have a recipe for making those tasks far less of a chore.

.NET 4.0 added quite a number of helpful little classes that “wrap” another type. It’s a very useful capability of the language. Since they don’t usually meverage .NET 4.0 or 4.5 features, you can often backport the class functionality. Arguably the only reason they are even in the library now is because they became something of a fundamental class in numerous available libraries.

One of these such classes is the ThreadLocal<T> type (ThreadLocal(Of T) for VB.NET, naturally). The purpose of this is to have a variable who’s value is separate on different threads. This can be useful for any number of different reasons. .NET 4.0 adds this class to the System.Threading namespace. The functionality, of course, can be useful in previous Frameworks, so it can be necessary to reconstruct the class.

That is what I’ll be doing here. The ThreadLocal&ltT&gt type has a relatively simple interface; it implements IDisposable and contains only a few methods, so it’s ripe for duplication for use in previous framework versions for which the Base Class Library lacks it. I will call my implementation “ThreadVariable”, but it could simply be called ThreadLocal instead, allowing code written using the variable for use in the BCL to work in previous framework versions (other framework differences notwithstanding, of course).