Finished another chapter in my book, Input/Output, which deals with the following:

Implementing serialization and input/output functionality in a .NET Framework application

Nice things I learned from this is how to easily compress and decompress data.

More importantly, the reason it is so easily, is because of the important role Streams play in the Framework. Once you get your head around streams, it's easy to use various sorts of them to get things done.

Another best practice I picked up, is to stop writing application specific configuration data to .xml/.ini files, but store them in the IsolatedStorage, it's the new Registry! :)

Besides the basic fundamentals of working with streams and the nice features you basically get for free once you know how to work with them, there are also some helper classes to work with the filesystem.

If you got any questions on the articles, feel free to comment.


The book I'm reading to prepare myself is Microsoft.NET Framework 2.0 Application Development Foundation

Just finished the first chapter about Framework Fundamentals. Topics dealt with in this chapter are:

Developing applications that use system types and collections

It's quite basic, but interesting, at the start, explaining the difference between value types and reference types, combined with some information on Nullable Types and the StringBuilder class.

There are also some examples about boxing and unboxing, something which you had to think about a lot more in .NET 1.0/1.1 when we didn't have generics yet.

Also a more obscure feature of the framework, the TypeForwardedToAttribute Class, used to redesign your libraries without recompiling your consumers of the library.

A nice cosmetic feature is implementing the IFormattable Interface to allow consumers of your class to specify various display methods when calling ToString().

Another thing I got a better understanding about thanks to this chapter is operator overloading, for example to properly implement the IEquatable Interface, you would probably overload the == and != operators as well.

I finally managed to document a version of IDisposable which I like and understand.

To finish up, I'll never have any problems remembering how to wire up an event anymore with the EventHandler delegates.

Time for the next chapter now :)


Taking a little break right now, got a bit of a burn out, lack of sleep might have something to do with it :)

The ASP.NET MVC project I had in mind will have to wait a little bit, with a bit of luck it gives me time to find a good graphical designer as well, they seem so rare to find. If you know a good designer, please comment!

What I'm going to do however, is study for a Microsoft Certificate.

Normally I'm not into degrees, when I graduated I saw people graduate with the same degree as me, who could barely write HTML or C#, at which point I placed no value in the degree people have. I rather judge people on what they say and do, which is also the reason I never really bothered with certificates.

But even as a developer, you can't be blind to the world, certificates matter for non-developers. I admit it's a nice addition to a resume and leverage when it comes to negotiating your salary, however I'm starting to see some value in the certificate as well.

When you properly prepare for an exam, without cheating and learning all questions by heart, it's actually a good form of self-education. Even when you don't take the exam in the end, the stuff you pick up while learning the required matter for an exam is valuable.

All these little hidden things you learn about the .NET Framework help to broaden your background knowledge, tiny things which you'd never encounter normally. It helps you make you aware of all the features .NET offers you, and if it only helps you do one thing better, it still helped.

I could disappear for some weeks now to study and not write anything, but that's not me.

Instead, I've added a section to my wiki reserved for note taking and research on the exam itself.

It's not a tutorial, but I belief it does contain some nice "wow, that's cool"-things.

Going to keep you updated whenever I finish a chapter, with a small summary of the things I think are cool.


Welcome back for another episode in the pattern series! This will also be the last article about Design Patterns, since I've finished reading the Head First Design Patterns book :)

It's been a very interesting journey, lots of new patterns learned, lots of knowledge gained, and now it's time to apply them in real projects.

As a summary, the overview of all articles about patterns, including the one we're going to see today:

Let's get started! Make sure you're seated comfortable, it's going to be a long one today!

The definiton, as usual: "Provide a surrogate or placeholder for another object to control access to it."

A new request popped up, we need to add in a multiplayer option in our game, featuring a Lobby where users can get in touch with each other.

This lobby is going to be running on another machine, or in our case, just another console application to illustrate it.

First of all, we're going to start by adding an interface ILobby to define our lobby.

ILobby Interface

We'll place this interface in a seperate library, to better illustrate the Proxy Pattern later on. This way you can clearly see on which machine a specific piece of code is located.

Time to create our actual Lobby implementation!

As mentioned before, we will create this in a seperate project to clearly show the code for the Lobby is not located on the same machine as our main client.

Lobby Implementation

A very simple Lobby implementation, containing nothing more than a List<string> of Users.

At this stage, we can have our Lobby on one machine, but how do we add users to it from another machine?

This is where the Proxy Pattern comes looking!

Just to make one thing clear, the Proxy pattern comes in many different shapes, we're using it to give a client access to a remote object, by means of a placeholder, reminds you of the definition, doesn't it?

In our case, it's called a 'remote proxy', there is also a 'virtual proxy', a 'protection proxy' and more.

A virtual proxy can for example serve as a placeholder for an object which is expensive to create, if you want to retrieve an image over the internet, you could display an icon via a proxy while the real image is loading in the background.

So, let's create this placeholder on the client side.

LobbyProxy Implementation

By placing a reference to our previously created ILobby, this proxy allows our client to work with, what it believes to be, a real lobby object.

In reality however, their is no Lobby implementation in our client code at all, it is merely a placeholder which implements the correct interface.

You might have noticed the notion of a Socket already :)

Our proxy object might implement the correct ILobby interface, if we want it working, we will eventually need to call our real Lobby object.

In a first step this is done using sockets to connect to the server and communicate with the real object.

Before you go screaming .NET Remoting, hold your horses! This is meant to illustrate what is going on behind the scenes with a remote proxy.

When you're coming from the Java world, you might have heard people mentioning a Skeleton.

This is not something creepy, but simply a class on the server side which intercepts call from the Proxy, talks to the real object and sends the results back.

Here's a small part of our Skeleton code:

Proxy and Skeleton Code

As you can see, the Proxy talks to the Skeleton, which talks to the Real Object, after which it sends the response back over the wire.

When we put all of this in action, we see the following happening:

Testing Proxy Pattern

Our main client talked to a remote Lobby and registered some users, great!

Now that we've seen how a proxy serves as a placeholder, it's time to clean this code and get rid of all the socket stuff.

Just a note, all the socket stuff in the project is highly unstable and not meant for production! Don't use it!! It's only meant for demo purposes :)

Let's work on the server side first by removing the Skeleton code, referencing System.Runtime.Remoting, and letting our Lobby class inherit MarshalByRefObject.

Lobby Remoting Implementation

Last step needed for our server is to expose the Lobby object through Remoting, which is nothing more than having something like our previous Skeleton code hidden behind the scenes.

Exposing Lobby Remoting

The only thing left to do now is to remove the Proxy class from our main project, and use Remoting to get an instance of ILobby, which acts as a proxy behind the scenes.

Utilizing Remoting Proxy

Resulting output when we run this version? Exactly the same! But a lot less work to implement :)

And that's it, another pattern in our heads!

I've uploaded the solution again to have a look at. When you run it, make sure your run the GameServer first, unblock it on your Windows Firewall, and then run the Proxy project.

Well, that's it, the last part of my series. I hope you liked them and learned a lot from it. Be sure to keep on visiting for some other tech subjects coming up soon.

You can always subscribe to the RSS feed to stay informed.

Thanks to the people who were generous enough to donate a little bit after reading some of these articles! (If you'd like to donate, simply use the PayPal button on the left :))

See you soon!

Some additional information on the Proxy Pattern:


It's been a while again, but it's time for another pattern. Today we'll look at the State Pattern.

First of all, the definition: "Allow an object to alter its behavior when its internal state changes. The object will appear to change its class."

An additional request has surfaced today, we need to keep track if a unit is alive or dead and let it respond differently based on the state it is in.

Initially we solved this by introducing a new enum called UnitState and adding lots of switch() statements to our code.

Initial State Implementation

In the long run however, this would mean we have to keep on going into those statements whenever a new state needs to get added, which isn't exactly following the Open/Closed Principle we talked about.

Let's refactor this and introduce a new interface called IUnitState.

State Interface

Instead of using an enum, we're going to introduce two new classes, which implement IUnitState to represent our different states.

Concrete States

By seperating the logic for different states in different classes, we can add a new state easily, by simply creating a new class, and we keep our code base structured.

For example, the most simple state looks like this:

State Implementation

When we pull all of this together we get the following class diagram, illustrating two concrete states and the state interface.

State Pattern Class Diagram

To the outside, whenever the internal state changes, it looks like the object, GameUnit, changed it's type because a different concrete state is providing an implementation for the actions.

When we test this code, we can see the behaviour of internal state changing after the first Kill() command.

State Pattern Class Diagram

I realize this isn't the best example given to illustrate the State Pattern, I'm not quite that happy with it, stretching the game example like that, sometimes it works out, sometimes it feels a little forced, like today. I hope it made sense, be sure to check out the sites below for some other examples as well.

I've uploaded the solution again so you can have a look.

Some additional information on the State Pattern: