Contracts as a part of the type system? (No Interface Without Contract – Part 7)

Contracts? What are Contracts? And why are they reputed to be concerned with the type system? Aren’t they just injected into the executable? Is there maybe “more” behind them? And how should they really be used? Read this post for clarification.

Looking back

There have been ? parts of the series “No interface Without Contract?” now. It’s not that I told you everything about Microsoft Code Contracts yet and there is nothing more to introduce. In fact this will not be the last part, but there will follow about three.

If you look at the previous parts, you will notice that they are quite distanced: All their content stands – less or more detailed – in the Code Contract’s manual. Thus, you may have noticed that I did not really go “deeper” by talking about my experience using them.

What are Code Contracts?

The reason for that is simple: I did not really think about one question: What are Code Contracts?

No Interface without Contract? – Part 6: Object Invariants

Invariants are a kind of postconditions which apply to all members. How to formulate them using Code Contracts?

In the previous part we got started using Microsoft Code Contracts and formulated first pre- and postconditions. We only looked at “simple” ones. In this posting you will learn what object invariants are and how they are connected with Code Contracts.

What are Invariants?

As anticipated in the introduction, invariants can be compared to postconditions valid for all members of a class. In fact, you are actually able to modulate them using Contract.Ensures(invariant) in each member.

However, they are more than simple postconditions – they are always valid, regardless of the object’s state. So invariants must never be broken during an object’s lifetime. Thus, other members can rely on them like on preconditions.

MVVM Part 6: InteractingViewModel / IUserInteracter

How can ViewModels become nearly independant from their concrete view but still keep the control over it?
IUserInteracter can be an answer.

Note: This posting is part of a series. See MVVM-Library for other parts and download.

As the last part of this series is more than one month ago, I really have to publish this now So please excuse some undocumented parts, unfinished classes and not working code in the MVVM-Library. I will correct it later.

Where did we breake off?

In the last part we were able to abstract the user interface using the IUserInterface interface. At the end, we could use this IUserInterface to show IShowables. However, we do not have any Showables yet – so we can not really use our IUserInterface.

What this part is about

Now we want to connect the IUserInterface and our ViewModels.

Let’s start!

Performance Comparisons (a Helper Class)

Not very special but useful: A helper class for performance comparisons using a Stopwatch.

You may know the Stopwatch class which enables much more accurate performance tests than the DateTime struct.

This little helper class makes it use a little bit easier and more comfortable.

Sample Test

Let’s look at a sample test first which introduces the syntax:

static void Main(string[] args)
{
    PerformanceTestRunner runner = new PerformanceTestRunner(1000, WhileLoop, ForLoop);

    runner.Run();

    foreach (PerformanceTestResult result in runner.Results)
        Console.WriteLine("Result of {0}: Minimum: {1}; Average: {2}", result.Test.Name, result.MinimumTicks, result.AverageTicks);

    Console.ReadKey();
}

Distinguish between overloaded methods in XML-Comments

XML-Comments are quite handy when documenting public methods / classes. But what about method overloads in “see”-Tags?

Today when documenting some methods of a class using XML-Comments, I got a ReSharper message saying

Ambiguous reference Bar

However, ReSharper did not provide any automatic solution. So I had to find one myself

Pitfalls and Best Practices to prevent them #4 – Object Finalizers

Let’s help the .NET Garbage Collector! Why this often backfires…

You know that the .NET Framework comes with a Garbage Collector to tidy up unreferenced objects. And you also know that there are so called “Finalizers” (sometimes also called “Destructors”) which are executed before an object’s memory is definitely deallocated.

Examples

Some people may think: “Hey – let’s help the Garbage Collector a little bit” and write code like that (Note: The console output is for a later example only):

[WPF] Hide the “Window Buttons” (minimize, restore and close) and the icon of a window

No “Red-X”? Then I can’t close the window! How to achieve this reaction in WPF applications.

Even if it is not always the user friendliest way, there are situation in which you do no want the user to close a window using the “red X” in the upper right corner of a window’s non client area (sometimes only called “Close Button” ).

In most cases this behavior is expected from Dialogs which usually do not have “Minimize” and “Maximize” buttons. So it’s a common practice to hide the whole so called “System Menu”, “Control Box” or “System Bar”.

Windows Forms

It’s quite easy to do so in Windows Forms: Simply set the ControlBox property to false:

No Interface Without Contract? – Part 5: Using Microsoft Code Contracts

Microsoft Code Contracts? Get started using them!

In the previous part we had a first look on Microsoft Code Contracts. This part will help us getting started using them.

Download and Installation

To use MS Code Contracts you need at least the Standard Edition of Visual Studio 2008 (VS 2010 is also supported).

No Interface Without Contract? – Part 4: Writing down Pre- and Postconditions

Contracts are important – we already saw this. What can we do that we always see them when coding?

In the previous part, we formulated pre- and postconditions for a sample class. However, we only have written them down in plain text.

So we are now finding out how to specify them in a more comfortable (and elegant of course ) way.

I will introduce five possibilities: Documentation, Exception / Assert based, Custom Checker Class, Attributes and Code Contracts.

Threatfire and Visual Studio –> Debugging slowdown

Something prevented me from debugging!!! Why this excuse can be true in some situations.

Some days ago, I noticed that the Visual Studio 2008 debugger suddenly was very, very slow.

A simple “Step Over” took up to 10 seconds. Even worse was the performance of the “Immediate Window”. When evaluating an expression, the output was terribly slow, too.

As debugging in such a low speed is no fun any more, I had to find the reason. First I thought that changed settings, windows or plugins are responsible.