Archive for the ‘Architecture & design’ Category

Problems and Solutions with Model-View-ViewModel

My MSDN article on the MVVM design pattern is finally available!

Unfortunately, Figure 1 is not correct;  we’re working on getting that fixed in the article. In the meantime here’s a corrected version:

  • The WPF Utilities component should not depend on any unit tests
  • The unit test components should not depend on any other unit testing component
  • The domain model should NOT depend on the data access layer.  Instead, the data access layer should depend on the domain model.  The domain model is the core of everything.  Acthieving this is not easy, and I’ll post about how to achieve it.

Let me know what you think of the article!


Coding without a license 2: Getting your license

There’s a very interesting discussion on stack overflow right now about learning how to program:

Beautiful, elegant, and smart too.Yesterday, my pair-programming partner mentioned that he thinks code should be art.  A few weeks ago, another programmer said she wanted to write beautiful code.  These are awesome goals, and I it made me happy that they even realized these are laudable goals; code, application design, and a running program can (and usually should) be beautiful and elegant.

So, I’m going to start a series of posts all about beautiful coding, elegant designs, and creating wonderful applications.

The advice on the above stack overflow discussion is very good, and I recommend reading it.   A related post is Joel’ Spolsky’s excellent “The Perils of Java Schools”.

Certainly there’s nothing better for learning about how a computer works internally than programming 2D or 3D graphics routines in assembler and linking that to your hybrid C/C++ program managing the rest of your game.  If you’re using a C++ object oriented approach for the elements of your game (weapons, characters, land tiles, whatever) then you can start to get a sense of good object oriented design.

However, my understanding is that very few game programmers are doing things in assembler these days – DirectX with C/C++ is blazingly fast, and DirectX with .NET is usually fast enough and is much nicer to program in with its automatic memory management and the extensive functionality of the .NET framework.

At the heart of becoming a great programmer is – not surprisingly – a desire to become a great programmer!  You have to want to write beautiful code using elegant designs to produce wonderful applications.  You have to want to write code that you can be proud of, even years later.

It’s going to take at least 10 years.  That’s not 10 years working in a big corporation where 50% of your time is writing TPS Reports, 20% is in meetings, 10% is office gossip, and 10% 😉 is maybe spent fixing somebody else’s mess with the cacophony of 5 simultaneous conversations about TPS Reports rage in the cubicles around you.


To really learn to program you need to work on things you’re passionate about – a small personal project, or better yet a large personal project.  There’s nothing better than fixing bugs in your own code 2 years later while cursing the idiot that wrote the code for not using a better design and writing some useful documentation.

image My own project was a 75,000 line artificial intelligence natural language application written in C++ (and later migrated to C#) that I started shortly after graduating university.  It was really hard and I made a lot of mistakes.  I fixed them.  I made more mistakes, and cursed myself for repeating some mistakes, and then I fixed them.  Over 3 years I worked on this project a lot; I learned a lot.

Similarly, back in high school and university I programmed games.  I made a lot of mistakes there too, and I learned a lot.  A few years ago somebody said to me, “I wish I had your knowledge of computers”.  I replied, “It’s easy, just devote years of your life to programming something you’re passionate about.”  He didn’t seem interested, and fair enough, but that’s why I can charge a lot for my consulting time.

Of course I still make mistakes, although it’s a lot less now than I used to, and usually I make new mistakes.

I studied math at university, and the amazing thing about studying math is that you’re usually being taught things first discovered hundreds or even thousand of years ago; Newton published Principia Mathematica over 300 years ago!   Computer science and object oriented programming are really only about 50 years old (and yes, I’m not talking about the difference engine), so it’s only natural that as a discipline we’re all still learning.  Which, really, is great because it’s a lot of fun.

Coding without a license – ubiquitous method parameters

I saw some very poor code today, and amazingly it was written by a programmer of 10+ years.  The programmer had updated an existing class by adding a new parameter – exactly the same parameter – to each and every method of the class.  In fact, the object couldn’t work properly without this information.  Here’s my Java pseudo-code version of the updated code:

public class Before {
    public Before() {...}
    public void SomeMethod(int x, int y) {...}
    public void AnotherMethod(int x, float y) {...}
    public void AThirdMethod(int x, String a, String b) {...}
    public void YetSomeOtherMethod(int x ) {...}

He had also deprecated all the previously existing methods, figuring I guess that he could simply force all users of this highly shared component to update all their code.

I politely pointed out that if the data was always required, perhaps it would be better to require the data in a constructor.  Here’s  my Java version of the same change:

public class After {
    public After(int x) {
        this.x = x;

    public void SomeMethod(int y) {...}
    public void AnotherMethod(float y) {...}
    public void AThirdMethod(String a, String b) {...}
    public void YetSomeOtherMethod() {...}

    // A new immutable variable, which completely
    // eliminates the pervasive x parameter
    private final int x;

This has a number of benefits:

  1. It simplifies the method signature of every method in the class
  2. It eliminates the need to check the parameter’s validity in every method. Instead, the parameter can be checked once by the constructor.
  3. It allows the variable to be frozen to avoid accidental tampering – in this case using Java’s “final”, but this can also be done in C#’s using “readonly”, or in VB.NET using “ReadOnly”.
  4. There is no need to deprecate all of the existing methods
  5. It may be possible to leave previous constructors in place and assume a reasonable default, or even use the C++/C#4/VB.NET feature of default parameter values to reduce rework (although this requires a re-compile).

In this case, the change was even more egregious because the class was actually implementing an interface, and the programmer had updated the interface.  Updating the interface required all implementations of the interface to pass in the “x” parameter – but “x” was an implementation detail!  So the other implementations didn’t need anything to do with “x” whatsoever!  (“x” wasn’t an integer in the real code).  Instead, using the constructor approach above, any consumer of the interface remains unchanged, and other implementations that do not rely on “x” also remain unchanged, so the impact to the API and the many, many applications that depend on the API is much less.

Think before you code, and document as you go.