Friday, March 27, 2009

The Query Command Separation principle, who was right?

Yesterday, at my Design Patterns & Testability session at the dotNED meeting, I tried to explain the purpose of the Query Command Separation principle. However, somebody from the company Quadrant (forgot to ask for his name) mentioned an entirely different explanation of the pattern. Since many design principles are not very well specified, I was expecting some discussion, but in this case, I was caught off guard a little bit.

He was explaining it as a pattern for distributing changes over multiple synchronized databases. For instance, when one database is used for reporting or querying and the other for maintaining state, command-like objects are used to apply the same change to both databases. I heard about this approach and it sounded like the Command pattern. However, he mentioned an article from Greg Young posted on Code Better, so it sounded serious enough for me to investigate.

Turns out we were both right. As a technical design pattern, the QCS principle does indeed what I though it did and has been written down by Bertrand Meyer. At the same time though, Greg Young and Udi Dahan and some of their fellow Distributed Domain Driven Design guys have been redefining this pattern on the architecture level. You can read about that over here.

Slides from the Design Patterns & Testability session at dotNED

As usual, I ran out of time big time, but still, it was a great evening. We continued until 21:45 and even though my throat was hurting as hell due to the flu, people were paying attention very well. TDD en testability are really difficult subjects and always cause a lot of discussion, but the discussion itself already proved some of the claims I made. So, I'm happy!

 DSCF1184

You can download the slides here and the code that shows all the examples I had in mind (and failed to show within the available time) here.

Sunday, March 15, 2009

Dutch Open Space Code Day 2009

Open Space Code is a hands-on programming event following the Open Space format. The concept was borrowed (with permission) from the Open Space Coding Day that was held in the UK recently. Open Space events are more freeform than normal conferences, where all the interactivity is mostly found in coffee breaks. Mostly they're just great fun.

twitter

Announcements will be posted on this website and on this Twitter account @openspacecodenl, if you want to attend, send an email at info@openspacecode.nl.

The target date is Saturday the 6th of June 2009 from 9.00 to 17.30, the target location is in Den Haag near the A4 but hasn't been confirmed yet.

Design Patterns & Testability at dotNED and SDN

March will be busy month for me. On Thursday the 26th of March, we will be hosting the monthly Dutch dotNED community at the Holiday Inn hotel in Leiden. I'll be talking about testability and design patterns by showing how Test Driven Development and Design Patterns can help you create highly maintainable software. I'll start with a short introduction on TDD and list quite a few principles that I've learned from some of the more noticeable members of the community. I'll then continue with coding an example application using various design pattern and in TDD-style. Check out the registration page here.

On Monday the 30th, I'll repeat the design patterns part of that session at the quarterly SDN Event in Driebergen. And if you're into testability, you'll be in for a joy because quite a few sessions will be covering that subject.

Friday, March 06, 2009

New coding guidelines for C# 3.0

Update June 29th, 2010
This document has just gone through a major update for both C# 3.0 and C# 4.0. Read more about it here and get the document from http://www.csharpcodingguidelines.com/.

I have been a long-time supporter of coding standards because I believe in its value as a way of improving overall code quality and helping inexperienced developers to gain more insight on the consequences of their work. I wrote my first C# Coding Standard together with Vic Hartog in 2003 for Philips Medical Systems, but have been refining these since then. However, I think every architect or lead developer should decide for himself whether or not he or she wants to comply with each and every rule, so I decided to refer to this document as Coding Guidelines rather than Coding Standard.
In the last couple of months I’ve been busy trying to revise this original document in order to come up with a version suitable for C# 3.0. And since Visual Studio has great support for automatic code checking using its Static Code Analysis feature, I decided to remove any overlapping rules and guidelines. The new document should be used as a companion to Code Analysis/FxCop and adds additional best practices that have proved to be very useful in my daily work as a consultant.