Peter Ritchie's MVP Blog : C#

Unit testing WCF data contract serialization.

PeterRitchie — Tue, 05 May 2009 02:30:00 GMT

WCF service define "data contracts" for their interfaces. These contracts are often defined in an XML schema document and used to generated WCF data contract code. This process effectively creates a .NET type that will serialize to a chunk of XML text.

Depending on the operation of the WCF service, its code may be responsible for creating some of these objects. A return value from an operation, for example. While the framework handles XML serialization of these object behind the scenes. But, if your have complex types and you end up not setting all the properties correctly in your object tracking down what properties haven't been set properly can be a chore as the server would have to enable passing exceptions back to the client, etc.

A technique that I've found useful is to add unit tests to ensure the creation of my contract objects are indeed serializable.

For example, I may have an method GetCustomer that retrieves a customer. Where I would like to create this contract Customer I would create a method to create this contract object based on parameters, like a Model Customer object.

For example:

    PRI.ExampleWcfService.Customer ToWcfContractCustomer(PRI.Model.Customer customer)
    {
        //...
    } 

Now, one of the unit tests would call this method and attempt to serialize the object to XML text, for example:

    [Test]
    public void WhenCreatingCustomerContract_EnsureXmlSerializationSucceeds()
    {
        PRI.ExampleWcfService.Model.Customer customer = CustomerRepository.Get(1);
        PRI.ExampleWcfService.Application.Customer contractCustomer = ToWcfContractCustomer(customer);
        String text = Utility.ContractObjectToXml(contractCustomer);
    } 

where Utility.ContractObjectToXml is declared as:

    public static class Utility
    {
        public static string ContractObjectToXml<T>(T obj)
        {
            DataContractSerializer dataContractSerializer = new DataContractSerializer(obj.GetType());
 
            String text;
            using (MemoryStream memoryStream = new MemoryStream())
            {
                dataContractSerializer.WriteObject(memoryStream, obj);
                byte[] data = new byte[memoryStream.Length];
                Array.Copy(memoryStream.GetBuffer(), data, data.Length);
 
                text = Encoding.UTF8.GetString(data);
            }
            return text;
        }
    }

Now, when this unit test is run, it will fail if the serialization process throws an exception because the resulting XML would violate the schema.

See [DataContractSerializer.ReadObject is easily confused] for why I'm creating a new buffer and copying the serialized data before converting it to a string.

DataContractSerializer.ReadObject is easily confused.

PeterRitchie — Thu, 30 Apr 2009 02:14:41 GMT

With WCF services you need to declare contracts and generate contract classes that encapsulate those contracts. Most of the time you can simply let the framework deal with whatever it needs to do to deal with these objects. Sometimes, you need to actually see without running a service what XML would result from a contract object or serialize a contract object from XML text.

In .NET 3.5 there exists the System.Runtime.Serialization.DataContractSerializer class that perform serialization of data contracts.

Based on its documentation it seems fairly simple to create data contract object to/from XML methods. For example:

    public static T XmlToContractObject<T>(string xml) where T : class, IExtensibleDataObject
    {
        MemoryStream memoryStream = new MemoryStream(Encoding.Unicode.GetBytes(xml));
        using (
        XmlDictionaryReader reader = XmlDictionaryReader.CreateTextReader(memoryStream, Encoding.Unicode,
                   new XmlDictionaryReaderQuotas(), null))
        {
            DataContractSerializer dataContractSerializer = new DataContractSerializer(typeof(T));
            return dataContractSerializer.ReadObject(reader) as T;
        }
    }
 
    public static string ContractObjectToXml<T>(T obj) where T : IExtensibleDataObject
    {
        DataContractSerializer dataContractSerializer = new DataContractSerializer(obj.GetType());
 
        String text;
        using (MemoryStream memoryStream = new MemoryStream())
        {
            dataContractSerializer.WriteObject(memoryStream, obj);
 
            text = Encoding.UTF8.GetString(memoryStream.GetBuffer());
        }
        return text;
    }

But, when you try to perform a round-trip from a contract object to XML and back you'll notice that you get SerializationException with the cryptic message of "There was an error deserializing the object of type <sometype>. The data at the root level is invalid", despite that the XML seems view when examined.

When Encoding.UTF8.GetString is called, it literally translates the entire array into a String object. This means that it reads any and all 0 bytes in the array and dumps out null characters ('\0') into the string. Why do I mention this? Well, MemoryStream uses a self-expanding buffer to write to. When MemoryStream runs out of space in its buffer, it doubles the size of the buffer, zeroes it out, then copies the original buffer to the start of the new buffer. When MemoryStream.GetBuffer is called it simply gets a reference to this buffer, regardless of how many bytes have been written to the stream. So, most of the time you get a buffer with zeroes padded to the end of it.

If you look closely at the resulting XML, there are a bunch of '\0' characters at the end of the string.

As it turns out, DataContractSerializer.ReadObject (or something it calls) doesn't like all the extra null characters and this is the cause of the SerializationException.

Irritating as this may be, the fix is fairly straightforward. Simply, create a new buffer equal to the length of the stream and copy the data from the MemoryStream buffer to the new one--trimming all the extra zeroes. For example:

    public static string ContractObjectToXml<T>(T obj) where T : IExtensibleDataObject
    {
        DataContractSerializer dataContractSerializer = new DataContractSerializer(obj.GetType());
 
        String text;
        using (MemoryStream memoryStream = new MemoryStream())
        {
            dataContractSerializer.WriteObject(memoryStream, obj);
            byte[] data = new byte[memoryStream.Length];
            Array.Copy(memoryStream.GetBuffer(), data, data.Length);
 
            text = Encoding.UTF8.GetString(data);
        }
        return text;
    }

Evolving code over time

PeterRitchie — Tue, 31 Mar 2009 04:02:00 GMT

Given economics, time constraints, resource limitations, etc.; you can't write all the functionality for a given solution for a single release. Even if you weren't limited by these constraints, you're likely to get changing requirements as development progresses and everyone learns more about the software under development.

It's fairly easy to prioritize what is developed and what isn't. You simply develop only what you need (see YAGNI). But, how do you manage adding new functionality without causing undue grief? One way is to only make additive changes to the code. For example, let's say we have the method create CreateRequestPacket that creates a blob of bytes to send to a host over the wire:

public static byte[] CreateRequestPacket()
{
    byte[] result = new byte[12];
    result[0] = REQUEST_CODE;
    result[1] = NO_OPTIONAL_DATA_FLAG;
    result[2] = (byte) (result.Length - 2);

    Random random = new Random();
    for(int i = 3; i < result.Length; ++i)
    {
        result = (byte) (random.Next() % byte.MaxValue);
    }
    return result;
}

In iteration x it writes out a request making certain assumptions about what the request contains. But, in iteration y it needs to optionally include other data. A non additive way is to simply modify CreateRequestPacket to do what is needed:

public static byte[] CreateRequestPacket(bool useOptionalData)
{
    byte[] result = new byte[12];
    result[0] = REQUEST_CODE;
    result[1] = OPTIONAL_DATA_FLAG;
    int index = 2;
    if(useOptionalData)
    {
        result[index] = GetOptionalData();
        ++index;
    }
    result[index] = (byte) (result.Length - index);

    Random random = new Random();
    for(int i = index + 1; i < result.Length; ++i)
    {
        result = (byte) (random.Next() % byte.MaxValue);
    }
    return result;
}

Now all calls to CreateRequestPacket need to change before a build can occure and you might not be able to modify all the files that contain these calls. So it causes undue blocking and forces you to change a number of files before you can check the file that CreateRequestPacket is contained withing.

Another way of implementing this would be to implement an additive change. That is, add a method that does what is needed and change the previous implementation to call the new method. For example:

public static byte[] CreateRequestPacket(bool useOptionalData)
{
    byte[] result = new byte[12];
    result[0] = REQUEST_CODE;
    result[1] = OPTIONAL_DATA_FLAG;
    int index = 2;
    if(useOptionalData)
    {
        result[index] = GetOptionalData();
        ++index;
    }
    result[index] = (byte) (result.Length - index);

    Random random = new Random();
    for(int i = index + 1; i < result.Length; ++i)
    {
        result = (byte) (random.Next() % byte.MaxValue);
    }
    return result;
}

public static byte[] CreateRequestPacket()
{
    return CreateRequestPacket(false);
}

This allows you to check the file that contains CreateRequestPacket in right after passing unit testing and allows you to gradually change all calls to CreateRequestPacket as time permits.

DevTeach 2009 Vancouver

PeterRitchie — Thu, 26 Mar 2009 16:33:00 GMT

The schedule for DevTeach 2009 Vancouver has been announced (http://www.devteach.com/). There’s lots of great software development sessions from some of the leaders in our industry.

If you’re planning on improving yourself, this is the conference to go to. Not only can you attend excellent sessions; but you can hob-knob with the presenters and pick their brains.

If you have a friend or co-worker who’s interested, there’s a limited-time two-for-one offer for an even better price: http://www.devteach.com/Register.aspx

Pass-through Constructors

PeterRitchie — Fri, 21 Nov 2008 18:09:00 GMT

Pass-through constructors is a term I use to describe parameterized constructors that have none of their own logic and simply pass parameters to the base class. For example:

    public class BaseClass
    {
        private String text;
        public BaseClass(String text)
        {
            this.text = text;
        }
    }
 
    public class DerivedClass : BaseClass
    {
        public DerivedClass(String text)
            : base(text)
        {
        }
    } 

Pontificating Virtual Parameterized Constructors in C#

PeterRitchie — Tue, 18 Nov 2008 17:55:00 GMT

Tom Hollander recently posted about a change he required to the Enterprise Library for date/time validation. He had to create a new class (rather than modify the Enterprise Library) that derived from another, defective class. One of his complaints was that in order to effectively implement the base class he had to also write matching constructors that simply called the base class. His suggestion was effectively to add the concept of virtual parameterized constructors to C#. I detail “parameterized constructors” because C# already effectively has virtual default constructors. In the following example the base constructor (Form()) is automatically called by the derivative:

    public class MyForm : Form
    {
        public MyForm()
        {
        }
    }

Virtual parameterized constructors are not new, and from a mere language standpoint this seems reasonable. Pragmatically though, I believe, this is another story. It seems logical to be able to simply inherit the parameterized constructors of the base class; but, there are so many times that this isn't the case or some generally accepted principles that would be contravened by a language addition like this.

Let's first look at the open/closed principle (OCP). The OCP suggests classes should be open for extension but closed for modification. Robert Martin suggests [1] properly designed class hierarchies that obey OCP implement an abstraction; i.e. derive from an abstract class or implement an interface. For example:

public interface IShape
{
    void Draw(Graphics graphics);
}
 
public class Rectangle : IShape
{
    //...
    public void Draw(Graphics graphics)
    {
        ///...
    }
}

Second, let's look at the "prefer composition over inheritance" principle. The effect of a language change like this on a design that prefers composition should be fairly obvious. Here's an example of this principle:

public interface IPolygon {
    void Draw(Graphics graphics);
}
public sealed class Polygon {
    private readonly Point[] points;
    public Polygon(Point[] points) {
        this.points = points;
    }
    public void Draw(Graphics graphics) {
        for(int i = 1; i < points.Length; i++) {
            graphics.DrawLine(Pens.Black, points[i-1], points);
        }
    }
}
 
public class Rectangle : IPolygon {
    private readonly Polygon polygon;
    public Rectangle(Point location, Size size) {
        Point[] points = new Point[5];
        points[4] = points[0] = location;
        points[1] = new Point(location.X + size.Width, location.Y);
        points[2] = new Point(location.X + size.Width, location.Y + size.Height);
        points[3] = new Point(location.X, location.Y + size.Height);
        polygon = new Polygon(points);
    }
    public void Draw(Graphics graphics) {
        polygon.Draw(graphics);
    }
}

Obviously there is no way to use virtual parameterized constructors here.

Clearly, designs that take into account OCP and prefer-composition-over-inheritance would not benefit from a "virtual parameterized constructor" language addition.

Finally, let's look at why a class might have many constructors causing such friction for derivatives. There's many reasons why a class might have many constructors. I believe all are indications of a poorly designed class. My first thought would be that many constructors is a result of a large class and that the large-class-code-smell should be an indication for redesign. A large class could be in an indication of a motherclass; but in either case this is likely a single responsibility principle (SRP) violation and the class is doing much more than it should and be redesigned. If the class isn't large but has many constructors, this was likely done not in response to how the class should/would be used but to cover every possible way of constructing the type. This would then be a YAGNI violation and the number of constructors should simply be pared down.

But, what about when you have to deal with poorly design hierarchies and don't have the ability to modify them? A valid point; but, simply for the lack of friction of writing pass-through constructors I don't think adding to the language to support poorly designed classes is a good for the language or its developers.

While an addition like virtual parameterized constructors seems benign, its limited actual usefulness makes the effort not worth the reward. Plus, it introduces greater abilities to create poorly designed types.

[1] http://www.objectmentor.com/resources/articles/ocp.pdf

.NET 4.0, Evolving .NET Development

PeterRitchie — Wed, 12 Nov 2008 16:02:00 GMT

.NET 4.0 is the first release of .NET since 2.0 that evolves .NET for every programmer. .NET 3.0 was largely LINQ and .NET 3.5 was largely new namespaces (like WCF, WWF, etc.)

.NET 4.0 evolves the programming and design for any programmer. It offers framework support for parallel processing (PFX will be released), Code Contracts (now DbC is a reality at the framework level, and opens the possibility of it being a reality at the language level post 2010), variance changes (co- and contra-variance on generics interfaces and delegates is now a reality).

Parallel Processing
Moore's law has changed from single processors doubling in speed every 18 months to doubling in processing power through increased core count every 18 months. This means for applications to make use of processing power increases they must increasingly make use of parallel processing and multi-threading. The PFX makes this more a reality by providing a framework by which application designers can more easily write code to support multi-core processors and multi-processor computers.

With PFX writing a loop to make use of multiple processors (while still supporting single processors) will be as easy as:

    uint[] numbers = new uint[] {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20};

    Parallel.ForEach(numbers, delegate(uint number) { Trace.WriteLine(CalculateFibonacci(number)); });

Code Contracts
Design by contract is a form of writing software with verifiable interface specifications. These specifications can be used at compile time to find code that breaks the contract and not require checking of the contract at run-time. For example:

    [ContractInvariantMethod]

    public int Calculate()

        int result = 0;

        foreach (int value in values)

            this.operation(ref result, value);

        return result;

If anything modifies the current class within the Calculate method, an exception will be thrown at run-time. Compilers will eventually be able to perform rudimentary checks at compile-time to ensure these contracts are abided by. For example:

    [ContractInvariantMethod]

    public int Calculate()

        int result = 0;

        foreach (int value in values)

            this.operation(ref result, value);

        this.date = DateTime.Now;

        return result;

...may eventually cause a compile error on the assignment to this.date. The person designing this type intended this method to be invariant, meaning it doesn't change the state of the object to which it belongs. This design attribute can now be guaranteed.

Being able to include more design aspects in code and code definitions is a great step forward in not only writing intention-revealing code but in the ability to write more reliable code.

Variance changes

C# has always had intuitive variance when it came to arrays. For example, the following is valid code:

    Shape[] shapes = new Triangle[10];

Given:

    class Shape {

        //...

    class Triangle : Shape {

        //...

Generics variance was a different storey.  Prior to Visual C# 2010, this following is a compile error:

    Func<Triangle> triangle = () => new Triangle();
    Func<Shape> shape = triangle;
 
...despite Triangle being a type of shape (or otherwise known as "bigger" than Shape).  This is known as invariant. In Visual C# 2010 you can now create delegates (as well as types and methods) that are no longer invariant.  For example, a Func delegate could be created that is covariant:
        delegate T Func<out T>();
(not the new use of the out keword) ...which could make our previous code:
    Func<Triangle> triangle = () => new Triangle();
    Func<Shape> shape = triangle;
...compiler without error.
 
The same can be done for contravariance with the the new use of the in keyword:
        delegate T Action<in T>(T value);
 
For more details on generics variance, please see Eric Lippert's series on generics variance: http://blogs.msdn.com/ericlippert/archive/tags/Covariance+and+Contravariance/default.aspx

Other
Another notable improvement is side-by-side (SxS) support for multiple versions of .NET. This allows hosting of more than one version of the CLR within a single process. This makes writing shell extensions, for example, in C# a reality in .NET 4.0. You shouldn't need to target .NET 4.0, but as long as .NET 4.0 is installed you should be able to write shell extensions in a current version of .NET (like .NET 2.0) and it will be supported. Prior to .NET 4.0, a process could only have one version of the CLR loaded into a process, making extending 3rd party native applications (like the Windows shell) very problematic because what version of the CLR that was loaded into a process would depend on the first extension loaded. If the first extension loaded was a .NET 1.1 assembly then any other extensions loaded requiring .NET 2.0 would subsequently fail.

Becoming a Visual Studio Jedi Part 1

PeterRitchie — Tue, 02 Sep 2008 18:49:00 GMT

Becoming a Visual Studio 2008 (and often Visual Studio 2005) Jedi

In much the same grain as James' Resharper Jedi posts, I'm beginning a series of posts on becoming a Visual Studio Jedi. It involves getting the most out of Visual Studio off-the-shelf, doing things as quickly as possible and with as little friction as possible. I think it's useful for all users; but especially useful for those who are in situations where they can't install refactoring tools like Refactor Pro! or Resharper.

First, familiarize yourself with Sara's Visual Studio Tips blog; then subscribe to her blog.

I'll attempt to provide detail at a less granular level than Sara's blog (i.e. using a series of commands to perform a specific task); but I may overlap here and there

Take advantage of Auto-Hide
Like Jimmy Bogard and Jeffery Palermo, I have my Visual Studio UI very lean. 99% of the time, I'm working in code. The Solution Explorer (SE), Properties, Output, etc are auto-hide panes. When I need to use them I hover the mouse over the tab to make them visible, do what I need to do with them, then get back to the code. The Code Editor is the only window that isn't auto-hide or floating.

Navigate find results via keyboard
Whenever anything is displayed in a find results window, you can iterate each item in the list via a keystroke. The default C# keyboard map had F8 and Shift+F8 as the shortcuts for next and previous.

For example:

Press Ctrl+Shift+F to bring up the Find in Files form.
Enter "TODO\:.*refactor" in the "Find what" text box.
Ensure Match case, Match whole word are unchecked.
Ensure Use is checked and has Regular expressions selected.
Press Alt+F to search.

A Find Results window is displayed that shows the results of the search.

F8 goes to the first result.
Pressing F8 again goes to the next.
Pressing Shift+F8 goes to the previous result.

F8 and Shift+F8 work for most lists like Find Results 1, Find Results 2, Error List, Output:Build, etc.

File name extensions when adding classes
Do you find your self selecting text in the file name when you use the Add Class wizard? Or, do you always type ".cs" at the end of your file name? You may be happy to know you don't have to do that. Simply invoke the Add Class wizard and type the name of the class. The wizard adds the missing .cs for you. For example:
Press Alt+P, C
Enter "MyNewClass"
Press Enter
A file MyNewClass.cs is added to your project and it contains class named "MyNewClass".

Consider a Custom toolbar

There's generally only handful of toolbar buttons that you might need, especially if you're a keyboard user like me. There's some things that simply don't have a default keyboard mapping. Another good reason for having a custom toolbar item with only the buttons you use is if you often change the size of your Visual Studio window. The default layout has two or more toolbars (depending on the edition and any add-ins you have installed). You can carefully position those toolbars so they may take up one or two lines; but when you then shrink the size of your window the get wrapped and they won't restore if you expand the size of your window. Having a single toolbar means this wrapping of toolbars can never happen.

Export Settings

Once you get your UI the way you want it, you can actually save the layout.

Click on Tools\Import and Export Settings.
Select Export selected environment settings.

This is really handy if you get into low-resource situations (like the application you're developing or its framework uses up too many GDI handles and Visual Studio can't allocate a handle to display a toolbar or a frame. When this happens Visual Studio actually turns off those GUI elements; when you close and restart those panes/frames are no longer displayed by default.)

Trials and Tribulations of DataGridView, Column Selections, and Sorting

PeterRitchie — Tue, 26 Aug 2008 20:06:00 GMT

I had to implement some custom sorting in a DataGridView recently. Essentially, the stakeholders wanted full column selection (like Excel) while still having the ability to sort the data based on a particular column.

This particular DataGridView is data-bound. DataGridView offers the Sort(DataGridViewColumn, ListSortDirection) method to perform this. Nice and easy I thought: I’ll set the SelectionMode to DataGridViewSelectionMode.ColumnHeaderSelect and simply call Sort with the selected column.

Well, much to my chagrin this had the side effect of making that column look selected all the time. No matter where else I clicked, that recently sorted column looked selected (SelectedColumns had a count of zero). And to add insult to injury, when I control-clicked that column (thinking it was selected) to unselected it, it caused a NullReferenceException deep in the framework.

Suffice it to say, this makes it very difficult to sort by columns in DataGridView without using the built-in sort-column-when-header-is-clicked mode.

What I’m now attempting to do is to unselect the column before sorting it. This, in itself, is not trivial either; there’s no public method to select or deselect a column in the DataGridView. I’ve had to create a new DataGridView derivative and call the protected method SetSelectedColumnCore. A few hoops…

I’ve logged a couple of issues on Microsoft Connect about these problems. The first is about ctrl-clicking the column and getting an exception: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363623 The second is about the visual state of the column remaining “selected”: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363623 Attached to this post you will find the project referenced by the two Connect issues.

[Update: I've currently only tried this with a .NET 2.0 project in Visual Studio 2008 SP1; if you find this problem occurs in Visual 2008 RTM, please comment.]

[Update: I overlooked the DataGridViewColumn.Select property, so there's no need to derive from DataGridView]

DataGridViewColumn.Frozen

PeterRitchie — Mon, 11 Aug 2008 22:34:00 GMT

DataGridViewColumn.Frozen is documented as "When a column is frozen, all the columns to its left (or to its right in right-to-left languages) are frozen as well."

Which is nice until you think of the consequences. The consequences being that freezing a column and all columns to the left is performed with a single assignment of true to the Frozen property of that column; but to unfreeze is not the opposite (a assignment of false to the Frozen property of that column). No, you must unfreeze each of those columns to the left. This can be done by manually unfreezing each column, or by unfreezing column 0.

This means that column.Frozen = false is not the opposite of column.Frozen = true—resulting in unbalanced reversible side-effects.

Neither of the techniques to “unfreeze” the column that was frozen is intuitive; but unfortunately this interface is not "intention revealing". You’re not just setting the Frozen property of a column, you’re setting the frozen property of that column and all the columns to the left.

Greg Young recently commented (I don’t remember where) about writing classes without any properties. This approach would have helped here. What Greg is alluding to is to recognize behaviour rather than shape. Freezing the current column and all columns to the left is a behaviour, not an attribute; and it should be modeled as a method rather than a property.

At any rate, if you have a DataGridView on your form, you may be interested in using these methods instead:

        private void FreezeAtColumn(int value)

            dataGridView.Columns[value].Frozen = true;

        private void UnfreezeColumns()

            dataGridView.Columns[0].Frozen = false;

ITSWITCH #1: Answer

PeterRitchie — Mon, 28 Jul 2008 19:00:00 GMT

Last post I detailed some code that may or may not have something wrong in it. If you thought InitializeOne and IntializeTwo are semantically identical (e.g. they differ only by performance), you'd be wrong.

If you simply ran the code, you'd be able to guess where the problem is. To understand what's causing the problem. Let's look at how C# effectively implements the two loops.

InitializeOne is essentially equivalent to

        private class PrivateDelegateHelper

            public String Value { get; set; }

            public void Method()

                TestClass.ProcessText(Value);

        public void InitializeThree(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            MethodInvoker cachedAnonymousDelegate = null;

            PrivateDelegateHelper privateDelegateHelper = new PrivateDelegateHelper();

            String[] copyOfStrings = strings;

            for(int i = 0; i < copyOfStrings.Length; ++i)

                privateDelegateHelper.Value = copyOfStrings;

                if (cachedAnonymousDelegate == null)

                    cachedAnonymousDelegate = new MethodInvoker(privateDelegateHelper.Method);

                delegates.Add(cachedAnonymousDelegate);

Now it's obvious, right?

For those you don't want to read all the code, the problem is that only one PrivateDelegateHelper object is instantiated and its value property is set in each iteration of the loop. Because the delegates aren't run until sometime after the loop, they're all run with the last value of the string array as their argument.

The technical term for what we've implemented here is a closure. If you're using Resharper 4.x, you would have noticed a warning "Access to modified closure":

...which is attempting to tell you that the closure (the delegate and cached bound variables) has changed (in this case one of the bound variables has changed between the creation of a closure and another and out expected output is effected).

By the way, you can get the same thing with C# 3+ with lambdas (i.e. you can also write closures with lambdas):

        public void InitializeOne(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            for (int i = 0; i < strings.Length; ++i)

                String value = strings;

                delegates.Add(() => ProcessText(value));

        public void InitializeTwo(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            foreach(String value in strings)

                delegates.Add(() => ProcessText(value));

ITSWITCH: #1

PeterRitchie — Fri, 25 Jul 2008 18:58:00 GMT

Is There Something Wrong In This Code Here

UPDATE: as several readers pointed out there was compile error in the code what was being displayed. The line "String value = string" was showing up as "String value = string". I'm not sure why; but throwing some spaces between the i and the square brackets seems to have solved it.

In the following class, is there something wrong with either InitializeOne or InitializeTwo (hint, it has nothing to do with compile errors and I'm ignoring performance differences)?

    public class TestClass

        private List<MethodInvoker> delegates;

        private static void ProcessText(String text)

            Trace.WriteLine(text);

        public void Run()

            foreach(MethodInvoker invoker in delegates)

                invoker();

        public void InitializeOne(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            for (int i = 0; i < strings.Length; ++i)

                String value = strings[ i ];

                delegates.Add(delegate { ProcessText(value); });

        public void InitializeTwo(String[] strings)

            delegates = new List<MethodInvoker>(strings.Length);

            foreach(String value in strings)

                delegates.Add(delegate { ProcessText(value); });

Answer on Monday.

Nested Types

PeterRitchie — Tue, 15 Jul 2008 14:47:00 GMT

Recently Michael Features blogged about nested types. The title was almost "nested types considered harmful".

I don't agree. I don't agree that they're any more harmful than any other C# construct (except goto...). Nested types are like anything else in our tool-belt: they have a time and place and can be abused.

But, when to use them? Well, for the most part I agree with Michael, you should avoid them. But, there are times when they're simply the best solution in a given set of circumstances.

Let's look at asynchronous programming model (APM) in .NET.

        // Paraphrased from MSDN

        // Accept one client connection asynchronously.

        public static void DoBeginAcceptTcpClient(TcpListener

            listener)

            // Start to listen for connections from a client.

            Trace.WriteLine("Waiting for a connection...");

            // Accept the connection.

            // BeginAcceptSocket() creates the accepted socket.

            listener.BeginAcceptTcpClient(

                DoAcceptTcpClientCallback,

                listener);

        // Process the client connection.

        public static void DoAcceptTcpClientCallback(IAsyncResult ar)

            // Get the listener that handles the client request.

            TcpListener listener = (TcpListener)ar.AsyncState;

            // End the operation and display the received data on

            // the console.

            TcpClient client = listener.EndAcceptTcpClient(ar);

            // TODO: do something with client.

            // Process the connection here. (Add the client to a

            // server table, read data, etc.)

            Trace.WriteLine("Client connected completed");

In this simple scenario we are getting by with a state of simply a TcpListener object. In a more complex scenario, you'll likely also want a connection-specific queue, some sort of information about what to do after a connection, etc. While you can use existing types of have several collection instance fields to keep track of each of these things; you then have to introduce synchronization of those collections, managing the content of those collections, etc.--it's much easier and safer to send that information on the stack. One method I've tried is simply passing an Object collection as the state; but that quickly becomes hard to manage because of the lack of type-safety on the elements in the array (if I remove an element and replace it with another type, the compile can't know and I'll get a run-time error instead of a compile-time error). To get type safety I generally introduce a new type to aggregate all the types I need in this asynchronous callback. While this new type *could* be reusable by other classes; it likely isn't and I don't want to then be bound that that explicit contract I've signed by making the types publicly available. The only option of not making them publicly available is as private nested types. For example:

        private class AcceptTcpClientParameters

            public CommandQueue CommandQueue { get; private set; }

            public Command NextCommand { get; private set; }

            public TcpListener TcpListener { get; private set; }

            public AcceptTcpClientParameters(int commandQueue, int nextCommand, TcpListener tcpListener)

                CommandQueue = commandQueue;

                NextCommand = nextCommand;

                TcpListener = tcpListener;

        // Accept one client connection asynchronously.

        public static void DoBeginAcceptTcpClient(TcpListener

            listener, CommandQueue commandQueue, Command nextCommand)

            // Start to listen for connections from a client.

            Trace.WriteLine("Waiting for a connection...");

            // Accept the connection.

            // BeginAcceptSocket() creates the accepted socket.

            listener.BeginAcceptTcpClient(

                DoAcceptTcpClientCallback,

                new AcceptTcpClientParameters(commandQueue, nextCommand, listener));

        // Process the client connection.

        public static void DoAcceptTcpClientCallback(IAsyncResult ar)

            AcceptTcpClientParameters parameters = ar.AsyncState as AcceptTcpClientParameters;

            if(parameters == null) return;

            TcpClient client = parameters.TcpListener.EndAcceptTcpClient(ar);

            parameters.NextCommand.Process(parameters.CommandQueue, client);

I find this use of nested types to be more object-oriented (the needs of the DoAcceptTcpClientCallback are abstracted), more intention revealing, better implements Single Responsibility Principle (SRP), better separates concerns, more maintainable and more agile.

Now, to be clear; this is forced set of circumstances. You're using a library that implements the APM (right? You haven't implemented APM yourself...). But, that's my point--nested types are almost essential in a given set of circumstances.

Comparing CodeRush Refactor! Pro and Resharper 4, part 1 or N -- first glance.

PeterRitchie — Thu, 26 Jun 2008 01:17:00 GMT

Metadata view of code in referenced assemblies
This is a big one for me. For whatever reason, Refactor 4 (and prior) completely disables this and sends you to the Object Browser instead. You get metadata view with CodeRush Refactor! Pro.

Keyboard layout
As you might imagine, CodeRush Refactor! Pro and Resharper had completely different keyboard layouts. So, if you're used to R# then Refactor! Pro will take a bit of getting used to.

One thing I don't like with the default Refactor! Pro keyboard layout, is they've replaced Ctrl-. with Quick Navigation. I use Ctrl-. (instead of Shift-Alt-F10 to get at the smart-tag menu). Shift-Alt-F10 for smart-tag menu seems more common; so I'll have to get use to Shift-Alt-F10.

Refactor! Pro's Editor enhancements
R# doesn't change to how the editor looks as much as CodeRush Refactor! Pro. It has the Marker Bar, error/warning/info colouring, and action light-bulbs. Refactor! Pro with CodeRush has many more, like region painting, flow-break evaluation, Visibility Icons, structural highlighting, etc.

Real-time analysis
Both R# and CodeRush Refactor! Pro do real-time code analysis. R# has text colouring and the right-hand marker bar. CodeRush Refactor Pro has a marker bar on both the left and the right. The left marker bar in CodeRush Refactor! Pro highlights issues for each line, and the right (as does R#) shows a file-wide view of issues. I find the R# marker bar sometimes doesn't align with the scroll bar so that an issue may be beside the scroll-bar in the marker bar but is actually scrolled off the screen. CodeRush Refactor Pro doesn't do that and in fact shows the visible portion of the document in its marker bar. i.e. the marker bar is beside the Visual Studio Indicator Margin (where the breakpoint bullets appear).

Refactorings
They both have many of the same refactorings. When it comes to non-refactorings the two sometimes approach things differently. For example R# deals with adding members to a class through "Generate Code" list; whereas CodeRush Refactor Pro uses templates. E.g. in R#, to add a constructor you hit Alt-Ins and select Constructor. With Refactor you simply enter "cc "(that 'c', 'c', space).

Smart-Tags
Both approach smart-tags slightly differently. With R# they use the actions light-bulb at the left margin. This includes fixes for warnings, errors, plus refactorings, but doesn't include code generation options. CodeRush Refactor Pro uses an ellipsis-like icon that appears right at the site of the potential refactoring. Code Refactor Pro is a richer experience. It will show you the result of a refactoring with arrows showing where things will move, red strike-out showing what will be removed, and highlights for things that will be changed/renamed.

Entity Framework Petition of Vote of Non Confidence

PeterRitchie — Wed, 25 Jun 2008 17:21:00 GMT

I had intended to be happy simply being a signatory of ADO .NET Entity Framework Vote of No Confidence. But, there's people suggesting signatories of this petition are wackos or on the fringe.

Do yourself a favour and read the petition. Read what we have issues with and how we think Entity Framework (EF) can be improved to be a better product. Read seminal material by industry leaders on entity-oriented and object-oriented application development like Domain Driven Design, and Agile Principles, Patterns and Practices in C# (and the predecessor Agile Software Development: Principles, Patterns and Practices) and Applying Domain-Driven Design and Patterns: With Examples in C# and .NET. If after you have understand this information, you think being forced to use EF on a software development team would mean it would be hard to implement generally accepted object-oriented and entity-oriented design, the sign the petition.

Yes, you have the choice no to use EF; but you also have the choice to help people to not have to deal with the issues detailed in the petition simply because they were not made aware of them.

And despite the naysayers of people who think EF should improve, the ADO.NET team is listening and agrees.

Fundamentals of OOD Part 3: Method Cohesion

PeterRitchie — Tue, 10 Jun 2008 19:26:00 GMT

Single Responsibility Principle (SRP) helps us write more cohesive types and methods. Cohesion is the relatedness of the members of a type to each other and the relatedness parts of a method's code to other parts.

Method cohesion
Often times a method is not very cohesive, meaning the code that it executes relates to more than one thing. This can often be seen with a method that contains a large switch statement. For any invocation of the method only one case statement may be executed; meaning that blocks of code within the method don't relate to all the other blocks. Switch statements are often an indication that the design should be changed to be more polymorphic or introduce a pattern like the Strategy or Template Method patterns. Likely a concept of the design is implicit instead of explicit (at least no more explicit than an enum). For example:

    public class Set {
        public enum Operation {
            Unknown,
            Union,
            Intersection,
            RelativeComplement,
            And,
            Conjunction = And
        }
 
        public static IList<int> PerformOperation(IList<int> one, IList<int> two, Operation operation) {
            List<int> result = new List<int>();
            switch (operation) {
                case Operation.Union:
                    result.AddRange(one);
                    result.AddRange(two);
                    break;
                case Operation.Intersection:
                    foreach (int x in one) {
                        if (two.Contains(x)) {
                            result.Add(x);
                        }
                    }
                    break;
                case Operation.RelativeComplement:
                    foreach (int x in one) {
                        if (!two.Contains(x)) {
                            result.Add(x);
                        }
                    }
                    break;
                case Operation.And:
                    foreach (int x in one) {
                        if (two.Contains(x)) {
                            result.Add(x);
                        }
                    }
                    break;
                default:
                    throw new ArgumentOutOfRangeException("operation");
            }
            return result;
        }
    }

This code works; but it's far from cohesive. There are many combinations of execution paths this method can take, and each path is unrelated to the other paths. For example, the Union case has no relation to any of the other cases. Methods like this are also hard to maintain and prone to errors. Obviously if another member were added to Operation PerformOperation would have to change--making PerformOperation tightly coupled to Operation--not very object oriented.

This can be made more object-oriented by through Dependency Inversion and the Strategy Pattern:

    public class Set2 {
        public abstract class Operation {
            public abstract IList<int> Execute(IList<int> left, IList<int> right);
        }
 
        public class UnionOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                result.AddRange(left);
                result.AddRange(right);
                return result;
            }
        }
 
        public class IntersectionOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                foreach (int x in left) {
                    if (right.Contains(x)) {
                        result.Add(x);
                    }
                }
                return result;
            }
        }
 
        public class RelativeComplementOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                foreach (int x in left) {
                    if (!right.Contains(x)) {
                        result.Add(x);
                    }
                }
                return result;
            }
        }
 
        public class AndOperation : Operation {
            public override IList<int> Execute(IList<int> left, IList<int> right) {
                List<int> result = new List<int>();
                foreach (int x in left) {
                    if (right.Contains(x)) {
                        result.Add(x);
                    }
                }
                return result;
            }
        }
        public static IList<int> PerformOperation(IList<int> left, IList<int> right, Operation operation) {
            return operation.Execute(left, right);
        }
    }

Now each operation is encapsulated, explicit, PerformOperation need not change as new strategies are added, and we've completely avoided the InvalidOperationException.

Spaces or Tabs?

PeterRitchie — Mon, 26 May 2008 14:25:00 GMT

In this day and age it seems silly to get into a discussion about whether your companies coding guidelines should have a section mandating either spaces or tabs for indents. Tabs are clearly more flexible, but I really don't think it matters at all; people can easily read code that contains spaces or tabs.

But, Microsoft has departed from what seems to be the rest of the world and is mandating spaces in their new Microsoft Source Analysis Tool for C#.

Word is that an update will not only mandate spaces but mandate 4 for indents.

Again, I don't think it's much of an issue; except Microsoft Source Analysis Tool for C# doesn't offer a rule to mandate tabs over spaces. They're not providing a tool for organizations to use to enforce local coding guidines, but providing a tool to mandate Microsoft's coding guidelines.

The tool can be downloaded here and a discussion on tabs can be found here.

RFC: Conditionals on false

PeterRitchie — Sun, 11 May 2008 15:19:00 GMT

Just a small request for comments. Oren prefers

if (GetTrueOrFalse() == false)

...instead of

if (!GetTrueOrFalse())

Coming from 18+ years of C/C++ based language programming, I find either equally readable; but, I'm not always the one reading my code.

What are you thoughts? Do you prefer the negation operator (!) or explicitly comparing with the false keyword?

Fundamentals of OOD, Part 2 - Encapsulation Scope

PeterRitchie — Thu, 08 May 2008 20:01:00 GMT

Let's look at the ubiquitous Person concept. It might seem logical that an application that deals with people should have a Person interface for classes to implement. For example:

public interface IPerson
{
                String GivenName { get; set; }
                String SurName { get; set; }
                IAddress Address { get; set; }
}

At first glance this seems fine. The IPerson interface defines attributes that the application uses with most scenarios dealing with types of IPerson, it's "well encapsulated". But, the person concept is much more broad than what IPerson is modeling. IPerson hasn't fully encapsulated the person concept. A person could have parents, age, weight, height, etc. The application doesn't need this information so it's narrowed the concept of person to fit its needs. This is an incomplete abstraction. The type that the application needs (that is currently IPerson) should be fully abstract. Based on the IPerson interface, a better abstraction would be ILocatableIndividual.

Let's look at the opposite of not fully encapsulating a concept.

Let's look at another common concept, the Invoice:

public class Invoice
{
                Customer BillToCustomer { get;set; }
                Customer ShipToCustomer { get;set; }
                Datetime InvoiceDate;
                ICollection<InvoiceItem> InvoiceItems { get; }
                Single ShippingAndHandlingPrice { get; set; }
                Single CalculateSubTotal();
                Single CalculateTotal();
                Single CalculateGrandTotal();
                PurchaseOrder PurchaseOrder { get; set; }
                void Print();
}

Again, seems like a reasonable encapsulation; but it has an issue.

There's a fundamental principle of OOD called the Single Responsibility Principle. Robert Martin interprets the principle as "there should never be more than one reason for a class to change.". A class should model a single abstraction. For that abstraction to remain abstract the modeled class should have a single responsibility. In the case of Invoice, the invoice concept should only model behaviours and attributes of an invoice. An invoice does not print, something or someone else prints it. With the above Invoice definition should printing need to change Invoice must also change, event though what the invoice *is* doesn't change. Invoice is now coupled to how printing occurs. In Martin's terms, Invoice now has two reasons for it to change: when invoice attributes change, and when how printing occurs changes.

The Invoice class should be refactored by moving the Print method to another class. Likely this would involve MVC, or MVP where a view would be responsible for the "printed view" and a controller or presenter would be responsible for communicating with the model (Invoice).

Fundamentals of Object-Oriented Design (OOD) Part 1

PeterRitchie — Fri, 02 May 2008 03:50:00 GMT

With increased usage of patterns and situationally specific strategies, people sometimes lose sight of the concepts and principles behind these patterns and strategies and fail to follow them when they're not using patterns or strategies. I feel it's good to periodically review the fundamental concepts and first principles.

Object Oriented Design (OOD) attempts to help with the complexity of designing, writing, and maintaining software. It attempts to allow building of software by modeling real-world objects. As with any tool, it can be used improperly, but OOD attempts to facilitate simplicity, robustness, flexibility, etc.. OOD has many fundamental concepts. Some of these concepts include modularity, encapsulation, and abstraction. OOD deals with modeling behaviour and attributes of real-world objects.

Modularity is a technique of composing software from separate parts. At the lowest level of an Object-Oriented Programming Language (OOPL), this is the definition of a type (a class or a struct in C#/C++). Depending on the platform there may be various other levels of modularity. In C#, for example, modularity can occur at other levels like module (source file), namespace, netmodule, assembly, etc. Modularity is a form of encapsulation.

Encapsulation is a technique of hiding implementation details, grouping them together. In OOPL, the lowest level of encapsulation is the type level (again, class/struct in C#/C++). Implementation details (data) is separated from behaviour of a type. In some OOPLs both behaviour and attributes (properties, for example in C#) are separated from behaviour. This allows clients to decouple or to be not dependant on those implementation details. Encapsulation is a form of abstraction.

The ability to encapsulate related behaviour, attributes, and implementation allows programmers to utilize abstraction. Abstraction facilitates separation. OOPLs allows programmers to keep concepts separate by abstracting them from one another. Keeping abstract concepts separate allows these concepts to evolve and be used independently. Properly designed types allow abstraction; a File class can abstract the file system away from a particular file, for example. The file system is part-and-parcel when dealing with files; but while dealing with a File object, it is abstracted away.

Good OOD has as little dependencies between parts as possible. This is called lack of coupling. One part that uses another part means the part depends on that other part. Changes to the second affect the first. Good OOD also has parts that contain related behaviour and attributes. This is called cohesion. If all the behaviour and attributes are generally used together in each scenario, the part has high cohesion. If only some behaviour or attributes are used in each scenario, the part has low cohesion and likely should be split up. Some people only view cohesion and coupling at the class level, I've purposely said "part" because I believe these concepts need to live throughout the modeled system, from class-level details, to modules, to namespace, to assemblies, to layers, to components, to systems, etc.

I will continue this series with the fundamental OOD principles that all good patterns should enforce.