Heavy WPF Commands – Part I

.net, , ,

Recently, I had a conversation about how much logic a WPF command in .NET might provide and how few implementation it should contain. Basically, this conversation was triggered by different understanding of the semantics of WPF commands. I realized that there is a lot misunderstanding how to implement and use commands in WPF that causes trouble in understanding the program flow and hard to maintain code in the long term. Therefore, I decided this is definitely worth some research on WPF commands and their usage. This is the first articles in a series, I will focus on the usage of WPF commands, their meaning, various implementations and best practices.

The intention of commands are pretty clear described in the Commanding Overview MSDN article:

The first purpose is to separate the semantics and the object that invokes a command from the logic that executes the command.

Therefore, commands allow you to reuse parts of your application logic for different targets of of application while separating this logic from the actual user experience (UIX). Regardless whether implementing the logic using the code behind approach in WPF with RoutedCommands, following the MVVM pattern using RelayCommands or building composite applications using DelegateCommands and CompositeCommands, the concept behind commands stays always the same.

All this is made possible by the ICommand interface with its two method declarations CanExecute and Execute. Basically, this allows your UIX to ask if a certain action can be performed and of course to trigger this action. The one who asks for this is called command source. If the command tells it cannot execute this action, is usually disables itself.

The Idea behind WPF Commands

Which logic to perform is not within the concern of the command source. The command maps the “Do Something” call from the command source to the actual logic and invokes this logic on behalf of the command source. Consequently, the logic to be invoked should not be implemented at an instance of the command itself. Any command serves simply as a protocol between application logic and UIX and allows you to separate both from each other.

In a following articles, I will focus on various best practices how to implement commands before having a look in the different possibilities how to use them in common WPF as well as in composite applications.

Extension Method Naming Conventions Best Practices

.net,

With .NET Framework 3.5 Extension Methods were introduced to .NET developers. The concept of extension methods allows you to

“[… ] ‘add’ methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type.”

While the most common use for extension methods are LINQ standard query operators, extension methods provide aplenty of new possibilities. One issue one comes along is the correct naming if extension methods and their corresponding classes.

The signature of a extension method differs slightly from a common signature as the first parameter is preceded by the this modifier:

public static int WordCount(this string that)

I haven’t found much about naming conventions, most about naming the methods itself, how to organize them or what you should not do with them. If you have read through Robert C. Martin’s Clean Code you might know that naming is an essential foundation of clean code. I’ve read through a lot of code outside and inside of Microsoft, however, I haven’t seen anybody following global guidelines. There might be group specific conventions but nothing that seems to be applied by the majority of developers.

1. Name the type parameter that

This seems to be very odd, but naming the type parameter that has quite some charm. When reading the signature you immediately see the type parameter, when reading through the method body you always know that that is the type parameter the extension is written for. When reading through many extension methods I found it very pleasant to read those methods following this convention.

public static int WordCount(this string that)

2. Create dedicated static classes for each type

No matter whether you put the extension methods in a separate library, in a specific sub-folder within your project or somewhere random

a) Do create separate files for each class containing extension methods.
b) Do create separate classes for each set of extension methods for a certain type.

Once you follow these simple rules you can think straight forward about naming of classes containing extension methods. If you collect all extension methods within a single class (or file) you might end ob with a lot of obsolete code while your application evolves. Due to rewriting your code and refactoring your application same extensions might become obsolete or some classes you extend do not exists anymore in your project. Using dedicated files make maintaining your code base much more easy.

Classes for Extension Methods

3. Use the Extension suffix

During our day job we realized that naming the class with the suffix Extension provide good semantics of the class. This indicates clearly that you are dealing with a collection of extensions. For example, while using the using the Visual Studio Object Browser you can easily identify those classes providing extension methods.

public static class StringExtension
{
    public static int CountWords(this string that)
    {
        ...
    }
}

4. Name what is being extended

It seems to be a good practice to name classes after what they extend. If you follow the previous two guidelines this should be a straight forward job. In addition your code is good to read and easy to understand. In practice we came along various conflicts with already existing naming guidelines. Anyway extensions are a relatively new concepts and one would expect that there might be conflicts with already existing naming conventions. The following will illustrate one of those conflicts:

Naming conventions for Extension Methods

By convention interface names should start with a capitalized ‘I’. So odes ICalculator. Following the above guidelines you might consider naming the corresponding class providing extension methods for the interface ICalculator type CalculatorExtension. In this case it seems reasonable to neglect the convention for interfaces:

Consequently, ICalculatorExtension provides extension methods for the ICalculator type, CalculatorExtension provides extension methods for the type Calculator. This approach will not only increase the maintainability of your codebase, I will also allow new team members to orientate quickly in your codebase.

There are various reasons for and against naming conventions for extension methods. Once writing Reactive Extensions for .NET this might get even more complicated as you will write a lot of extension methods for dedicated purposes. However, for common codebases the provided guidelines might help to develop easy to read and maintain, clean code.