Contracts in Object Orientated Code

A school of thought, which is widely supported, suggests that when two pieces of code communicate they form a contract. That is if code A ("the client") calls code B ("the supplier") with some data it will expect code B to have certain behaviour, return certain data and handle exceptional/erroneous/odd inputs in a certain way. The idea is called "Design by Contract" (DBC).

It occured to me that DBC could be formalised by extending interfaces into Contracts.

About Design by Contract

In simple terms:

1. The Supplier expects input data to meet certain conditions - "pre-conditions"
2. The Client expects the Supplier to behave in certain way - if the Supplier changes or stores data as well as returning output data it is harder to predict what will happen.
3. The Client expects output data to meet certain conditions - "post-conditions"

Pre-conditions - the Supplier is responsible for checking pre-conditions

Behaviour - if the Supplier code does not alter the state of the system but instead just returns data to the client then the Supplier's code is said to be Side-Effect free - Functional Programming techniques attempt to minimise Side Effects and Imperative Object Orientated techniques attempt to Encapsulate them within a manageable number of lines of code. Behaviour is usually tested by injecting Mock Object's as input data into the Supplier.

Post-Conditions - Client test code is used to create Assertions about the Supplier's code. Test Framework's allow us to create Unit Tests that test different Post-Conditions.

How to extend Object Orientated (OO) Frameworks to support DBC.

Many OO frameworks such as .Net and Java leave it primarily upto the developer to use DBC techniques. As an example in C# a Pre-Condition might be:

if (inputParameter == null)
{
throw new ArgumentNullException("inputParemter");
}

This code simply checks an input parameter to ensure it is not a null reference and throws an exception if it is.

.Net does have an extension called Spec# that adds DBC functionality. Now I don't claim to be an expert on Spec# or any other specific DBC framework, however, it seems to me that DBC would be better implemented by "upgrading" interfaces into Contracts rather than decorating Classes with contract information.

Why extend interfaces to support DBC?

1. An interface by its nature has public methods, properties etc - it is public and therefore requires a contract
2. An interface can then have any number of concrete implementations, which all meet the pre and post conditions
3. An interface can then be a single port of call for all contractual information - function declarations, pre-conditions, post-conditions and exception types
4. This would negate the need for verbose commenting of functions and reduce the need for a throws keyword in Java
5. It would reduce the clutter in classes

An Example:

An interface IPerson, which has a single property Name, which cannot be null might look like:

contract CPerson
{
[PreCondition: NotNull(Name)]
string Name
{
get;
set;
}
}

A concrete class would then "agree to"/"support" a contract, including any Pre-conditions and Post-conditions etc.

Any thoughts on this idea are more than welcome!

Top 5 free .Net tools

On a daily basis I use some or all of the following tools for .Net development:

1. .Net Framework - it is perfectly possible to develop .Net applications without Visual Studio, this can be done by downloading the .Net Framework Software Development Kit and using your preferred Integrated Development Environment - Eclipse would be a good choice.
2. FxCop - an automated rules-based code auditing tool that audits your compiled code. Checks include: naming conventions, multilingual support, null reference checks for public methods and functions, to name a few. Rules can be turned off and on and new rules created.
3. .Net Reflector - uses reflection to reverse engineer .Net assemblies into managed code (c# or VB.Net). It can also decompile the .Net framework core libraries, which is invaluable way of both understanding the logic behind certain functions or improving your coding techniques (mind you there are times when you would like to rewrite some of the code :-)
4. NUnit - a port of the popular Java equivalent JUnit. A fast way to undertake Test Driven Development, especially with the next piece of software.
5. Test Driven .Net - an inspired piece of software that allows developers to run NUnit test cases from within Visual Studio. Literally right clicking a test case (and selecting Run test) to run a test or a test class to run a whole suite of tests! Cool!

Some other free tools I haven't used, but would love to get some feedback on are: NAnt (build manager), NDoc (C# automated documentation), CLR Profiler (performance profiles).

Also of interest may be the Mono Project that is a Linux/Solaris/Mac OS X/Windows/Unix implementation of the Common Language Runtime (CLR). This allows .Net applications to run on non-Microsoft platforms.

Book Review: C# Cookbook by O'Reilly

C# Cookbook is well worth purchasing and is aimed at moderate to advanced level C# developers. It gives good coverage of all the major system libraries and programming techniques and includes "recipies" on all the advanced .Net 2.0 functionality.

I typically end up purchasing 3 types of book on any new language I am learning. These include:

• Simple Practical Introductions - step-by-step guides that have plenty of examples and cover both the programming language and the development environment (I have managed to skip buying these recently in favour of internet tutorials)
• Reference Books - these cover all the core libraries associated with a language including all classes and their public interfaces
• Advanced Guides - specialist topics covered completely and in depth

C# Cookbook does not fall neatly into any of these categories. The Cookbook is about as close as any book to being a single source for C#. This is because it gives loads of practical examples (which are well written and not hacks), covers all the major areas and solves advanced problems. You need look no further to delve deeply into threading, generics, anonymous functions, collections and xml. Happy reading!

Installer Driven Development (tm)

Ever been in a software development project with limited specification, tight deadlines, grief, pain, and suffering -- a flying albatross that just won't die. Your cure may just be Installer Driven Development (IDD). The concept is simple: focus on your installer package first and your code second. If this sounds entirely insane and counter intuitive then read on (especially if you've worked on software projects that suck).

A typical project scenario - a la Dilbert.

Day 1: Senior Exec has great idea for making money by selling a new software product to customers
Day 2: Senior Exec speaks to a few Senior Exec's he knows working at Customer sites who say they think its great (this is undocumented, unquantified, unqualified and turns into a solid business case by "the Power of Management")
Day 3: Senior Exec tells Middle Manager that customers are demanding Product X the solution to all their problems and that they need it by Y, and by the way this is vital to the company and he could gete promoted yadda, yadda
Day 4: Middle Manager has meeting with Tech team who say, "sure we're great we can deliver X by Y" and so that albatross starts its run up....

Now, days 1 to 3 cannot easily be altered as they are outside your control, but day 4 can.

Revised Day 4: Middle Manager has meeting with Tech team who say, "we are going to use IDD to ensure that we involve the customer, get the specification 100% correct and can deliver a demo that we can install on customer's machines for them to beta in time Z."

This has just saved Middle Manager's arse and he runs off excited to tell Senior Exec.

What do you do next - IDD?

1. Get a good installer program (Macrovision will do).

2. For you to install your demo you will need to know exactly what types of machine the customer uses, what browser, whether their IT department would install it, security, what other software they use etc. Get the Sales team to find out who the customers are and as many other important requirements as possible, point the Sales team at the Marketing team for all Sales "Collateral" add the tasks to the bug tracking system with weekly email reminders.

3. For your installer to look good you will require logos, help documents, links to websites, flash animations and a community website for your Beta customers etc. Get the Marketing team going, point them at the Sales team for all the customer profiles, feedback etc and add the tasks to the Bug tracking system with weekly email reminders.

4. You need to know how many versions of the installer are required (for the Lite version of the software, the Enterprise version etc). Get the Legal department to start producing the license agreement and software contracts, point them in the direction of Middle Manager for all pricing, product roadmap etc, add the tasks to the Bug tracking system with weekly email reminders.

5. Now you can either:

a) Sit back and enjoy the bun fight and write some code or
b) gather as much information from the different departments as possible, undertake all deployment testing and write a minimal Demo program that will be installed successfully from day 1.

6. Finally, ensure you provide regular progress reports to Middle Manager, highlighting the outstanding issues in the Bug tracking system for Sales, Marketing and Legal departments and point out that they have been given weekly reminders of their tasks.

Enjoy!

Visual Studio Templates and Code Snippets are great, but ...

Anyone who has developed any Object Orientated code has re-written the same code patterns many times including creating a class (with comments), implementing getters and setters (or properties in .Net) and creating constructors. This is where templates and code snippets come to the rescue.

Visual Studio (Item and Project) Templates - when you create a new code file in Visual Studio you select from one of many default templates such as a Class, Interface or even a Windows Service. These then use code generation to fill in the blanks (such as a class name) and create your code for you. VS 2005 allows users to create their own custom templates, which is Great! I already have a class template, interface template and exception template customised with default comments, namespaces etc (actually the exception class is entirely generated for me). This is already saving time for myself and my team. Next up a Test Case template.

Visual Studio Snippets - these allow you to insert chunks of code into your file and then fill in the blanks, sort of like code-by-numbers. This is also great and I have created a code snippet for a property that cannot be initialised to null (I use this regularly as it is good design-by-contract programming). See example:

private $type$ $field$;

public $type$ $property$
{
get
{
return $field$;
}
set
{
if (value == null)
{
throw new ArgumentNullException("value");
}
$field$ = value;
}
}

Microsoft lovingly wraps a whole load of metadata around my code snippet in xml (the code is embedded into an xml CDATA section). This is also great and saves me time re-writing the same code.

And now for the 'but'... ...BUT this is entirely symptomatic of a broken programming paradigm. And in English - Object Orientated languages such as Java, .Net and C++ are flawed, as is the concept of Code Snippets and Templates.

The simplified logic as a Powerpoint bullet argument (hey, its late and I'm getting tired):

1. In a good programming language we would only need to write the property code ONCE, this point will not be explained as it is self-evident
2. We would therefore NOT need to insert and customize the same chunks of code in multiple locations
3. Which means Code Generation and therefore Templates and Code Snippets are redundant!!!

Templates and Snippets suffer from the code generation problem that once created, if the snippet or template are changed the code is NOT. This means that the programmer must then go through all their code manually finding and replacing the generated code.

A thought experiment - what if we were to utilise code generation NOT when we insert the Snippet into our class file, but when we compile the code and then refer to the Snippet instead. Hmmm, well this would be an improvement in that we would then only write our Snippet once, and wouldn't have to manually update any changes. Our new code could look like:

Snippet Property (type = String, field = myString, Property = MyString);

Or something along these lines. :-) The Snippet of code is now effectively a "Template" for a Property. And why not take it a little further, lets make everything a Snippet and make it so that Snippets can include Snippets and the compiler will generate all our code from Snippets. Oh S***, what about the metadata, that's in XML and our Snippets are in C#, how would we generate those, and hey, haven't we just changed our language into some new Snippet language.

The problem with Code Generation - is that we end up creating meta-languages (which is fine) that have a new syntax etc, because the language that the code is turned into is inadequate. A number of code generation frameworks use XML to store the customisable fields and XSLT to then generate the code (into C# or Java or whatever). Makes you wonder really, so what are the options:

1. Include a decent templating concept into the core language: Jura is an example
2. Use functional programming - C# is starting to do this, but the starting blocks of classes and properties and interfaces are hard to then abstract out.

And while i'm at it: any programming paradigm (Object Orientated programming) that requires design patterns is flawed. Mind you my hat goes off to the people who have managed to turn the design patterns into libraries using advanced OO techniques such as generics, reflection and code generation (there is a point to some of these techniques)!!!

To round up, code generation, templates, snippets and design patterns are all good concepts starting from a flawed language, namely an Object Orientated language.

Rant over :-)

P.S. just found this conference on Code Generation down the road from me - I might well attend!

What is programming?

A slightly philosophical title, which will no doubt end up with a lot of introspection, reflection and sole-searching (no really, looking at the bottom of our shoes and trying to extract meaning from a piece of chewing gum). Why ask the question? A little thought skittered across my brain and went something like this: "Does writing a function in an Excel spreadsheet consitute programming?"

This thought was closely followed by a number of other thoughts, such as, is writing HTML programming? what about if we use a tool such as Dreamweaver? Hey, even more bizarre - can the creation of a Word document be called programming? I mean after all in Office 2003/2007 saving the file creates XML, and so does Dreamweaver. Let's face it this is clearly absurd, right?

Ok, lets separate the tools we use, the output data we create and our thought process.

Does the tool maketh the programmer? - Nope, this should be obvious, as even a monkey could use some of the Visual tools out there and still have no idea what they are doing.

Does doing maths make you a Mathematician? - Nope again, although we may generate sums and equations it certainly doesn't mean we could qualify ourselves as numerate. But, just maybe this does mean we need to introduce a sliding scale of programming ability, the idea of programmerness or how much of a programmer are you? Let's face it Excel provides many levels of abstraction that allow you to use the sum function on a column of numbers in the same way Java abstracts away from assembly.

Our thought process - so maybe it is purely our ability to comprehend a problem and provide a software based solution that differentiates us as programmers.

In the end, this means that we as programmers can argue as much as we like about the merits of language X over language Y, but using a particular language does not imply that we are better than the complete dorks programming in Perl, which is disgustingly horrible to read and only a no-brainer would even try :-) Moving on, maybe, just maybe, we should be striving, nay, moving mountains to provide the best software we can by understanding the many different ideas in different languages.

And, a note from my wife, who avoids anything technical like the plague - there's an art to it!

Bugbears

Nothing gets me (or anyone else I have worked with) more wound up than unhelpful error messages, or even worse error codes! For that matter I get wound up (because I think I can do better) with any error messages at all. Here's the rational, using a day to day example:

RESTAURANT SCENARIO - You walk into a restaurant and site down. The waiter appears and says, "What would you like to order, sir?" To which you respond, "I would like the spaghetti bolognese, with extra parmesan and some garlic." Here are some potential responses when the spaghetti has run out:

1. No Response - blank stare - a system crash when everything hangs
2. "No" - the equivalent of an undecipherable error code, only a complete geek would NOT be offended, but instead look it up on the internet or a FAQ
3. "We have run out of spaghetti" - a typical response found by most software, it tells you the problem in a rather terse manner that leaves you feeling frustrated
4. "I am very sorry sir, but we have run out of spaghetti" - slightly better technique used by some websites, which leave you with a warmer feeling, but hell what do you do next?
5. "I am very sorry sir, but we have run out of spaghetti, perhaps you would like to try the lasagne, which is equally delicious." - not only does this describe the problem but gives the customer an option (or two)
6. "I am very sorry sir, but we have run out of spaghetti, we have more arriving tomorrow, perhaps you would like to try the lasagne, which is equally delicious." - not only does this describe the problem but gives the customer an option (or two) and shows the customer that the problem is being resolved

Of these, responses 5 or 6 are best, but software typically uses 3 or 4 and sometimes 2 (1 is typically outside our control). I have created 6 potential responses, but many more can be generated when pondering the following questions:

Does the user know an error has occured? Does the user know what the error is? Does the user know why the error has occured? Is the response user friendly? Does the user know what options are available? Does the user know how the problem will be resolved? Who is expected to resolve the problem, the user or the software? How is the message communicated? And, Is the user happy with the outcome?

This is one hell of a lot of stuff to think about for a simple error, but without it users will get frustrated, angry and stressed. This is BAD!!!

Simple Steps to reduce stress:

1. Use good coding practices/conventions to control errors/exceptional behaviour and validate input properly
2. Think about the a user's experience (be polite)
3. Give users options
4. Give users confidence that the error is a one-off (or very rare) and can be resolved
5. Resolve the error with as little disruption to the user as possible
6. gather feedback (in a non-intrusive way - you are now asking the user to do something when the software has died)

Some simple examples of where small changes make big differences.

www.petrolprices.com - in their forms they have textboxes that validate your entries immediately and put a bright green tick at the end. This saves unhelpful page refreshes where you then have to scan back through your web page to find the incorrect field entry.

Microsoft Feedback Gathering System - its optional, but at least it empowers users so they thinnk they can do something (if only a little)

Password reminder services - how annoyed would you be if you forgot your password and there was no option to get a reminder email!

Anyhow, without going on forever, think about the user, resolve the problem with as little hassle to the user as is feasible and ensure it doesn't happen again - You Bad Boy!

Technology Time Warp

In the last few weeks I have had cause to try out Lisp and Haskell, both of which are pretty old technologies (although Lisp beats Haskell hands down being specified in 1958 as opposed to 1990). I have come to some interesting conclusions (which surprised me, but will not surprise users to these languages). Firstly, that programming language progression is not linear and secondly that I had missed (but been using in XSLT) an important programming paradigm.

Why try Lisp and Haskell? .Net 3.0 have some interesting new features, which step out from the purely Object Orientated view of the world and allow us to do some pretty cool stuff. These are namely Functional Programming (of which Lisp and Haskell are pure examples) and LINQ which provide relational query, set and transformation programming. Anyone who has used a relational database will instantly grasp LINQ, but what is Functional programming?

Functional Programming - Wikipedia has a great description of FP, but in essence a FP function does not store any state information. You can therefore blackbox FP code and with the same set of inputs you will always get the same set of outputs. This has performance and maintainability benefits, as software can scale (see Google's MapReduce function) and will not have side effects (they are also thread safe).

Conclusion - Was it worth trying Lisp and Haskell - in one word, yes. These languages provide great run-time interpreters/compilers and it took all of 3 minutes after download to start writing some pretty cool programs. Mind you trying to take in a new syntax (or two) with entirely different programming paradigms was pretty hard, but the upshot is a new way of thinking about coding especially for those of us brought up on Imperative Object Orientated code.

Some cool references:

• Paul Graham on Lisp - a bit of a Lisp zealot, but is a great blog
• Technorabble - this guy got here before me!!!