Practical Patterns 1: Singleton

As I've mentioned before, patterns are practically a way of life for modern software developers. But too many programmers are still unfamiliar with them, even as they unknowingly use (or worse, re-invent) them. This series hopes to provide a solid introduction to pattern development in C#.

For the first entry in this series, I wanted to start simple, with one of the most popular design patterns: the Singleton. This is a pattern that many developers are familiar with, even those otherwise unaware of design patterns in general. This should give us a nice, gentle introduction into the topic. Even so, there's a lot of detail here that is often overlooked. (Singletons are also one of the most commonly poorly implemented patterns.)

As this is the first post in the series, I'm still working out the format. For now, each post will discuss a single pattern, broken down into the following segments:

• Who - The name and basic description of the patter.
• What - A longer description of the patterns behavior, requirements, and purpose.
• When - Major use cases and types of problems this pattern can solve.
• Where - The kind of applications, frameworks, and other patterns where this pattern is often found.
• Why - The reason we apply this pattern to solve a problem, as opposed to other possible solutions.
• How - A detailed implementation of this pattern in C#, and how it was derived.

So, lets get to it.

What is NP and why is it so hard?

For some reason that now escapes me, I recently got into a discussion with a fellow developer about the Japanese puzzle game Nurikabe in which I mentioned that solving Nurikabe was in NP. (In fact, "does this puzzle have a solution" is NP-Complete.) I then realized this person had no idea what I was talking about.

(UPDATE: I think this excellent STL video is what started this whole mess. Blame Stephan!)

If you spend enough time in certain areas of the computer industry (notably cryptography, language/compiler design, or game theory) you will frequently hear phrases like "this problem is NP-hard", or "that's equivalent to solving the halting problem." Claiming that a problem is NP-hard or even unsolvable is a very important statement, but one that is often misunderstood even by people with a general idea of what those terms mean.

So, as is my habit recently, I'm taking to my blog to expand on that conversation; this is somewhat outside the usual subject matter, but hopefully as developers you will find it interesting anyway. (And hope that no one at work ever asks me how a neutron star forms.) Also, fair warning: math ahead.

Marshaling UTF-8: Harder than it ought to be.

A few days ago, I was looking at the codeplex project libspotifydotnet, published by a friend of mine, Scott. The project is a managed wrapper around Spotify's cross-platform API which, of course, is written in C.

Some of you may know Scott as the author of Jamcast, a super-awesome media server that lets you play your local media library over all kinds of UPnP devices: game consoles, PCs, purpose-built DLNA devices, even an Android smartphone. Some of the most interesting interop work I've ever done has been to support Jamcast, including a fasincating dive into JNI and the Android bionic runtime. So, I was not surprised that this particular interop API yielded some more interesting stuff.

In this case, the wrapper around libspotify brought up a couple of issues that are commonly found in third-party libraries, particularly cross-platform ones, but rarely arise when you're doing Windows P/Invoke. The one I want to focus on today is the string handling: libspotify strings are UTF-8 encoded, and if you're not careful, this case wreak havoc on your interop code. So, lets see how to be careful.