Pattern Incorporation-

I have to develop applications that run on PocketPC, WindowsCE, Windows Desktop (any flavor), Tablet, SmartPhone, of course the Web, etc. I’m lucky I’m only dealing with Microsoft OSes as far as you can consider yourself lucky in that regard. There is talk of opening our backend to run on unix based system. Then some genius realised Macs run on a unix based backend so they are considering opening the UI to macs. You can imagine the nightmare.

A development language and IDE combination that lent itself to things like the MVP pattern would be extreemly useful. I could remove UI logic from the model and possibly only face a recompile on each target platform and/or OS. As it stands now I have to implement everything regarding an MVP pattern myself. Imagine an IDE/Form designer where you drop a TextControl on the form and the IDE asks you whether or not the Text property should be bound to the view and presenter…. It wouldn’t fix everything but it would raise refactoring to a higher level of architecture vs. plain coding.

Design by Contract:
You touched on this but I would like to expand a bit. Microsofts R&D team came up with a pretty cool model for doing Design by Contract work using Attributed programming. Check out Spec# and XC# for examples. I was somewhat put out that Microsoft did not include these in the 3.0 framework because I don’t see any disadvantage in doing so. With attributed programming you can literally take it or leave it.

For example: I write a method defined as
string DisplayPercent(int percent)
{
return string.Format(”Percent = {0}%”, percent);
}

Anyone can realize that the parameter passed in should be a value from 0-100 inclusive. However, as we all know, this method may be called 1000 times. Why check to see if the parameter “percent” is between the range through code? Let’s have true design by contract where we can set the valid values at the method level through attributed programming that can be picked up by not only the compiler but the runtime.

[ValidateRange(”percent”, 0, 100)]
string DisplayPercent(int percent)
{
return string.Format(”Percent = {0}%”, percent);
}

Let the attribute throw an ArgumentException to the caller not us.

If built into the compiler:

DisplayPercent(500);

should display an error during build. Obviously percentages and go below 0 and above 100. I’m only illustrating a point.

Now consider your documentation as a class library author. You could easilly pick up on the Attributes rather than method body code to create documentation of what the method requires to execute correctly.

Just some thoughts. Love the blog been reading a bit and posted earlier.

Dave Jellison