Extension Methods

Extension Methods were introduced in the revisions to the C# and VB .Net languages that accompanied the release of Framework version 3.5 in November 2007 (that is, C# 3.0 and VB 9.0 respectively). They allow developers to augment – to extend – existing classes and interfaces by facilitating the creation of new Methods, without breaking the encapsulation of the original type/interface being extended. This can be achieved without the developer having to create a whole new type that derives from the type they wish to extend, and without their needing to have access to or know about the internal implementation of the type/interface they are extending. Used sparingly and intelligently, Extension Methods can be an extremely powerful and useful technique in a developer’s repertoire. This article contains a brief background on the advent of Extension Methods, a discussion of the syntax for implementing them, and some suggestions as to where and when best to use them.

---

A little background...

It’s no accident that Extension Methods were first included in the same version of the .Net Framework that also introduced LINQ. A full discussion of LINQ and the capabilities that it appends to the .Net language is a separate topic for another time. In summary, though, and of relevance to the present topic, LINQ (Language Integrated Query) is a syntax extension of the .Net languages that allows types that implement certain existing Interfaces to be directly queried in a native language syntax that reads very much like the SQL statements that had hitherto traditionally only been used within DBMS such as SQL Server. Using LINQ, developers could for the first time query, sort, and otherwise work with types representing data collections in-memory. The following simple program demonstrates LINQ at work on a collection of type string[] :

using System;
using System.Linq;

namespace Demo
{
    static class Program
    {
        static void Main()
        {
            string[] _CapitalCities = new string[5] { "Edinburgh", "London", "Paris", "Rome", "Stockholm" };

            foreach (string city in _CapitalCities.OrderByDescending(city => city))
            {
                Console.WriteLine(city);
            }

            Console.ReadLine();
        }
    }
}

The above program produces a Console window, listing the five cities stored in the variable _CapitalCities in reverse alphanumeric order. It does this by accessing a new method for type string[] called OrderByDescending. If you remove the using System.Linq directive from the above program, you will find that the compiler no longer recognises a Method called OrderByDescending for objects of type string[]. So what’s going on?

Because the type string[] implements an existing generic interface called IEnumerable<T> that was defined in previous versions of the .Net Framework, and because a new class called System.Linq.Enumerable that was appended to Framework 3.5 by the designers of LINQ defines an Extension Method for IEnumerable<T>called OrderByDescending, variables of the type string[] acquire the new Method observed, which is only accessible within the context of any object that references the System.Linq namespace.

LINQ uses Extension Methods in this way to facilitate adding new functionality to existing Framework definitions such as IEnumerable<T>, for the purpose of enabling objects that utilise those definitions to be instantly usable in conjunction with the new LINQ syntax. Extension Methods allowed them to do this without causing breaking changes to designs that preceded LINQ, and which consumed the original, un-extended versions of those existing Framework objects. Alternative approaches by the designers of LINQ might have included updating all of the Interfaces that they wanted to add new functionality to (which would have been great for LINQ, but would have broken any existing designs that had used previous versions of the updated Interfaces as soon as those designs were upgraded to the new version of the Framework, thereby upsetting a lot of developers and system owners). Or, they could have created an entirely new set of Interfaces, based on the originals, but with the extra LINQ goodness included (would have needlessly added to the complexity of the .Net Framework, which already contained quite enough redundant but kept-for-reasons-of-backward-compatibility features and near-identical object definitions from earlier upgrades and improvements, and would furthermore have needlessly rendered LINQ unusable by existing objects that had implemented older versions of the superseded Interfaces). By using Extension Methods, the LINQ developers were able to add functionality to existing objects, in a way that would only be apparent within designs that utilised their new language feature, and that avoided producing unnecessary breaking changes for developers that were merely upgrading their designs to the latest version of the Framework, but who had no interest in utilising LINQ within their legacy designs. In the process of their work, the LINQ developers gave us a useful additional tool to make much the same subtle enhancements to our own established designs as they had to the preceding version of the Framework.

Implementing Extension Methods within your own designs...

The syntax of implementing Extension Methods for a given class is demonstrated below. Suppose you have an existing class defined in the following way:

namespace RPPClassLibrary
{
    public class Person 
    {
        public Person()
        {
        }

        public string FirstName { get; set; }
        public string LastName { get; set; }
    }
}

If you wanted to extend the class Person to include a new Method called FullName using Extension Methods, the syntax for doing so would be as follows:

using System;
using RPPClassLibrary;

namespace RPPConsumingAssembly
{
    static class Program
    {
        static void Main()
        {
            Person aRachel = new Person() { FirstName = "Rachel", LastName = "Pierson" };
            Console.WriteLine(aRachel.FullName());
            Console.ReadLine();
        }

    }

    public static class MyExtensions
    {
        public static string FullName(this Person pExistingObject)
        {
            return pExistingObject.FirstName + " " + pExistingObject.LastName;
        }
    }
}

The above scenario, where the developer has free access to the class they are extending, isn’t a particularly good example of when Extension Methods should be used, but it is nonetheless a simple enough scenario to demonstrate what the syntax for creating such a Method should look like. The above code snippet takes an existing class, Person, which resides within the namespace RPPClassLibrary, and extends it to include the newly-required Method FullName, only for objects of type Person that are defined within the scope of the separate namespace RPPConsumingAssembly. This is achieved by adding a new static class within RPPConsumingAssembly called MyExtensions. The Main Method of the class Program within RPPConsumingAssembly demonstrates using the new FullName Extension Method with an object of the freshly-extended Person type. The output of the program above is as follows:

To create an Extension Method for any existing class or interface, as the code snippet above demonstrates you need to create a static class at the top level of the namespace in which you want to consume the Extension Method, then create as many public static Methods within that static class as you wish to create Extension Methods for. It doesn’t matter what you call the static class that you use to contain the Extension Methods you define, it matters only that the parameter list for any Extension Methods you define within your top-level static class take the exact format shown above – i.e. (this Person pExistingObject) – changing the type Person for whichever class/interface it is that you are extending. You can include Extension Methods for entirely different existing types within the same top-level static class, provided your definition of each individual Extension Method makes it clear which type your new Method applies to.

When to use Extension Methods...

There is a school of thought that says: “Never!”. The reason for this viewpoint is that extending classes willy-nilly certainly could lead to confusion at a later date, if the class that is extended by Extension Methods subsequently gets directly updated at some point to contain some additional intrinsic Methods with the same signatures as the Extension Methods that have been defined in the interim by external consuming classes. There would be nothing in the compiler that would alert the original author of the class being reviewed to the fact that some consumer of their object had previously extended it in what would in some respects be a potentially conflicting change. What would happen in actuality if the developer of a since-extended class happened to add a new Method to their class that had exactly the same signature as an Extension Method that had been created by a consumer, is that the new internal Method would take precedence, and the Extension Method would be superseded and effectively ignored by the compiler. For example, imagine if the original class in the simple example presented earlier were to be revised at some point so that it looked like this:

public class Person 
{
    public Person()
    {
    }

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string MiddleName { get; set; }

    public string FullName()
    { 
        StringBuilder _FullName = new StringBuilder();

        _FullName.AppendFormat("{0} {1} {2}", 
            FirstName ?? "(No First Name)",
            MiddleName ?? "(No Middle Name)",
            LastName ?? "(No Last Name)");

        return _FullName.ToString();
    }
}

In this scenario, the assembly that consumes the Person class (which would still contain a now-obsolete Extension Method with the same name as the new internal Method FullName that has been added to the original Person class) would still compile, and the program would run without errors, but the output would now reflect the internal, subtly-different, definition of the FullName Method:

The basic issue that some developers have with Extension Methods is that, by some definitions, they break the key object-oriented design principle of encapsulation. That is, they begin to impact upon the ability of objects to contain and control their own definitions, and act as black boxes to consumers. This isn’t an entirely fair criticism since, as the above example demonstrates, the original object remains quite untouched by any external consumers implementing their own Extension Methods for their own internal consumption; there’s nothing about such Extension Methods that prevent the developer of the original object from continuing to be in full control of their object’s design (though there is certainly an impetus on the developer of any Extension Methods to consider the possibility of unexpected behaviour should any object they have extended subsequently have its design changed).

The encapsulation issue aside, as the historical example of the introduction of LINQ demonstrates, there are certain discrete circumstances when it can be very useful to be able to extend the existing definition of an established object, in a way that avoids creating breaking changes for existing consumers of the original object, but that still provides new functionality for new consumers of same. Where Extension Methods are most useful, therefore, is when you are reasonably sure that the object you’re extending wont be subject to further internal change, and the functionality you are adding is specifically useful within the context in which you are adding it.

Silverlight Overview

Recently, I worked on a project that involved the use of Silverlight. This entry provides a brief over of the technology, and an intro into some of the sub-topics that it encompasses.
 

---

Simplifying the topic a great deal, Silverlight is .Net’s competitor technology to Adobe Flash. Just like Flash, it can be used to provide rich interactive content such as applications and games, as well as rich static content like streaming video. Also like Flash, Silverlight’s initial adoption has been slow, with few websites presently using it as their main solution delivery technology. At the time of writing this article, Silverlight is in its fourth generation of evolution. That means that a lot of Microsoft research and development time in recent years has gone into a technology that isn’t, as yet, being received by a wide audience.

The technology itself isn’t what’s holding back adoption; the solutions it enables developers to provide are pretty impressive as rich internet experiences go. What has been inhibiting progress to date is the age-old problem of internet development: site owners typically want to make their content available to the largest audience share possible. To satisfy this, developers therefore typically prefer to build using established technologies that are already being received by a high percentage of their target User base. As a corollary, developers acquire more skills in those older technologies, which ultimately go on to become ‘golden hammer’ solutions to the problem of presenting content via the web: if the only solution developers are familiar with is a hammer, then every problem begins to look like a nail. It takes at least one truly ground-breaking site that provides significant additional gains for its Users, such as YouTube,  in order to push a given technology over the edge from being kooky but great, to being mainstream and the new norm that Users don’t just adopt, but expect, and that developers are eager to immerse themselves in and use to expand the possibilities of what they can provide. Silverlight has yet to find its YouTube.

Microsoft has encouraged the adoption of Silverlight by licensing it to small, innovative technology companies, who, in return for adopting the technology to build the solutions they provide, get to use the latest development toolsets for a fraction of the fee that those same tools would cost larger organisations. In the process, Microsoft hopes that a greater percentage of the developer community will become familiar with the technology, and that at least some of these early-adopter organisations will provide that ‘YouTube Value’ that encourages end user adoption.

The development tools themselves are intended to form a bridge between the related but until now often separate activities of abstract visual design, and underlying software engineering. Tools in the suite that supports Silverlight include Expression Blend (often abbreviated in its current release to EB4). EB4 is a tool primarily aimed at designers, that is often used by developers too (you’ll typically find developers with a Silverlight solution open in Visual Studio for coding on their main monitor, and the same solution open in Expression Blend on their second monitor for visual reference). Expression Blend allows designers to set the style of visual elements against actual .Net controls, rather than against abstract graphic designs as has often been the case in many types of designer/developer collaborative effort up until now. Blend is capable of opening an actual Visual Studio solution, facilitating the editing of visual aspects of the controls and assemblies therein in real time, and allowing designers to save those visual updates back to a project that is shared with their developer colleagues via TFS. For the first time, designers and developers are able to access the same source, for different purposes, collaboratively instead of independently. The Expression Blend integrated development environment looks like this:

You can see objects in various stages of design and development within the main window, either as a visual representation, as XAML alone, or in a split view displaying both formats as shown below:

The extensive use that Silverlight makes of XAML is the first real difference that you notice as a developer with a background in .Net technologies like VB, C# and ASP.Net. (Coincidentally, XAML is also used by WPF – Microsoft’s replacement development platform for Windows Forms – so time spent getting up to speed with Silverlight also helps developers in gaining familiarity with WPF). XAML fills a role broadly equivalent to that which Windows Forms Designer Files did for Forms development, and HTML Markup did for ASP.Net. That is, it stores the basic visual design of a given component, by declaring which sub-components exist, and what values public Properties of those components will initially be set to. Just like ASP.Net and Windows development, Silverlight controls also have a code behind page, where developers can add interaction and function to the visual designs produced in conjunction with designers.

---

That’s it for this brief overview. In future posts, I’ll be delving deeper into the specifics of how XAML looks, and how it works in conjunction with code behind pages to produce fully-interactive designs.

Implementation vs Interface Inheritance

.Net provides two discrete mechanisms of inheritance. These are known as Implementation and Interface Inheritance. There are plenty of articles out on the net that describe what these discrete types of inheritance are in terms of their core characteristics, and the distinctions between them, but very little information about why and when to use each type. As a consequence, many beginner developers tend to use Implementation Inheritance heavily, but take very little advantage of Interfaces at first, knowing their characteristics but being unsure of what they can do is actually useful for. This article provides a brief recap on the similarities and differences between these two types of inheritance, but is primarily intended to clarify not just how and what they do, but when and why you’d actually use them in a real-world design.

---

Possibly the simplest of the two types of Inheritance to grok the purpose of is Implementation Inheritance: you have a class, and, provided the definition of that class allows you to, you may inherit from that class. When you do so, your inherited class will have all of the same characteristics as the original, plus any further characteristics that you may choose to add. When using the above form of inheritance, you end up with a superclass defining a less specific object, and a subclass defining a more specific object. These class definitions are related in what is known as an inheritance hierarchy. A simple example is an object that defines the basic characteristics of a motor vehicle:

public class Vehicle 
{
    public int Speed{ get; private set;}

    public void Accelerate()
    {
        Speed++;
    }

    public void Decelerate()
    {
        Speed--;
    }
}

Keeping things simple, the basic Vehicle class above defines that objects of type Vehicle will have a read-only integer Property called Speed, and two Methods – one for indirectly incrementing the Speed property, and one for decrementing it, named Accelerate and Decelerate respectively. You can probably think of lots of other things that vehicles might also do. Some of the things you can think of will apply to all vehicles, and others will apply only to specific types of vehicle, such as a motorbike, a racing car or a milk float! The above approach gives you the beginnings of a class structure to add any characteristics that you might need to define for each of those sub-types of vehicle as and when they become relevant to your model, in the most appropriate place.

A simple definition of one of the possible sub-types of vehicle, Car, is shown below:

public class Car : Vehicle 
{
    public Car(int Doors)
    {
        NumDoors = Doors;
    }

    public int NumDoors { get; private set; }
}        

The above definition declares that objects of type Car inherit from the superclass Vehicle, and so Car objects will consequently have all of the characteristics of Vehicle –type objects. The definition of Car augments the definition of Vehicle by declaring an additional integer Property called NumDoors, which can only be set when instantiating a new object of type Car, and thereafter is only accessible as a read-only Property (which makes sense, since cars generally don’t change the number of doors they have during their lifetime!).

So far so good. Most people learning object-oriented design for the first time tend to understand Implementation Inheritance as described above fairly easily and intuitively, probably because it’s an approach that’s most often used where the developer has control over the full design, perhaps acting as part of a small, self-contained team, and consequently they get to affect and influence the definition of pretty much every class in the various hierarchies that make up the whole design they’re involved in. There are a couple of simple, basic rules to remember, such as you can only inherit from one base class, and some types of class (known as sealed classes) can be deliberately designed so as not to be inheritable from, whilst others (known as abstract classes) can be designed so that they must be inherited from. Overall, though, Implementation Inheritance is a fairly easy concept for most developers to get their head around quickly, and produce useful designs from, that minimises code repetition and promotes separation of concerns. Then comes Interface Inheritance!

The first time you see Interface Inheritance, you could be forgiven for wondering exactly what the point of it is? Firstly, unlike Implementation Inheritance, you can inherit as many Interfaces as you like on a given class (somewhat confusingly, this is commonly referred to as ‘implementing an interface’, rather than ‘Interface Inheritance’, but I’ll use the latter less ambiguous phrase in this article to avoid confusion with the separate topic of ‘Implementation Inheritance’ described above). Secondly, interfaces, unlike base classes, can’t contain any actual implementations of Properties, Methods, etc: they can only define that certain characteristics will exist, and it is for the objects that inherit that Interface to define exactly how they work in relation to the inheriting object.

So, what’s the point in defining objects that you don’t actually provide the inner workings of? Going back to our vehicle example, if we instead defined vehicle type objects as an Interface, it might look something like this:

public interface IVehicle 
{
    int Speed { get; set; }

    void Accelerate();

    void Decelerate();
}

Notice that you can’t any longer provide a definition of the inner workings of the Accelerate and Decelerate Methods: you can only define that those Methods will exist, and any arguments they will take. Notice also that you can no longer set the scope for the Properties and Methods that the IVehicle interface defines – every Property and Method is inherently public, and must remain so (even adding the scope ‘public’ to the definition of any Property or Method in an Interface will cause a compilation error, and the compiler will tell you that scope can’t be defined for discrete characteristics of an Interface). This gives a clue as to what the purpose of an Interface actually is: unlike Implementation Inheritance, Interface Inheritance is intended to be of benefit to consumers of third-party objects that inherit them, not the inheriting objects themselves. The above example demonstrates exactly what most new developers find confusing about the purpose of Interfaces: there’s nothing about the IVehicle interface defined above that is inherently useful to designers of the classes that will implement it, since it leaves the majority of the work of defining how the Methods, Properties, etc, that each inheriting class must have up to the designer of the inheriting class, making the Interface itself pretty redundant in terms of code reuse.

The real benefit of Interfaces comes when you need to define some discrete characteristics of a third-party object, the detailed design of which you can’t control, but that will nonetheless be required to be consumable by some other object that you do control. Imagine for example that you’re designing a new data grid, that allows information of an as-yet unspecified form to be presented in an Excel-like format:

Column 1	Column 2	Column 3	Column 4
some data...	some data...	some data...	some data...
some data...	some data...	some data...	some data...
some data...	some data...	some data...	some data...
...	...	...	...

As the designer of this new grid object, you decide that you’d like the available data to be presented as text in ‘normal’ viewing mode, and that when a User clicks on an individual cell, the underlying data will become editable in some detailed way that consumers of your grid will define. So, if the data in question happens to be a person’s first name, then the appropriate control to present for editing that data when the user clicks in a cell containing that type of information will possibly be a Textbox; it’s really for the consumer to decide. If the data is a graphic (and the text represents some meaningful title for the image), the consuming developer might choose to launch the User’s default image editor, and allow the underlying image to be edited there. If the data represents co-ordinates on a map, the control that allows editing to take place might be a complex custom widget that integrates with Google Earth, and allows a set of co-ordinates to be selected by clicking on a 3D map, and returns a text representation of the latitude and longitude that the position clicked by the User represents. The point is, as the designer of the flexible data-editing grid, you don’t know (and won’t want to become overly-concerned with) any of that potential complexity, but you do want to be able to provide a generically-useful grid to facilitate editing, and you do want to be able to present the outcome of any edit operation that might happen within your grid, whilst leaving the complexity of how specific edit operations are implemented for discrete types of data up to other developers with more specific design considerations of their own. To achieve these objectives, you employ an object-oriented design principle known as abstraction. That is, you define a minimum subset of Properties, Methods, etc that any controls that will be used to edit data in your grid must implement, without getting into how those Properties and Methods will be implemented in each specific case. It enables you to provide other developers, who may be working entirely separately from you, with a roadmap of which specific qualities they need to build into their objects in order to ensure that those objects can work in harmony with your design. This is exactly what Interfaces allow you to achieve, and precisely what they are useful for.

Although as the designer of the data grid above you don’t know how complex or simple the data your consumers will need to present on a given occasion will be, and consequently how complex any specific editor controls will be, you can define a relatively-simple interface that consumers of your grid must implement in any controls they want to use for editing, if they want to use their control with the grid you have designed. One simple definition of an Interface to be inherited by an editing control might be:

// IGridCellEditControl definition,
// utilising a public delegate

public delegate void OnEditCompleteHandler(object oldValue, object newValue);

public interface IGridCellEditControl 
{
    string TextRepresentation { get; set; }

    event OnEditCompleteHandler OnEditComplete;
}

This simple Interface defines that any controls that will be used to edit data in the grid must as a minimum implement a string Property called TextRepresentation, and an Event called OnEditComplete. For simplicity in this example, the Interface doesn’t declare other characteristics that might additionally be required for a full solution.

With the above Interface defined, the developer of the grid can focus on designing the object they have responsibility for and control over, without concerning themselves too much about the inner workings of any third-party editor controls that may reside within and work in conjunction with their grid. The developer of the grid can therefore focus on the problems that are within their control and sphere of influence, safe in the knowledge that any third-party objects will behave in a certain way as a minimum subset of their behaviour. With that knowledge, the definition of a class that represents one cell within the data grid might look like this:

public class GridCell 
{
    public IGridCellEditControl EditControl
    {
        get
        {
            return EditControl;
        }
        set
        {
            if (EditControl != null) EditControl.OnEditComplete -= new OnEditCompleteHandler(OnEdit);
            EditControl = value;
            DisplayValue = EditControl.TextRepresentation;
            EditControl.OnEditComplete += new OnEditCompleteHandler(OnEdit);
        }
    }

    public string DisplayValue { get; private set; }

    private void OnEdit(string oldValue, string newValue)
    {
        DisplayValue = newValue;
    }       
}

This class defines a GridCell object as having two Properties (a string Property called DisplayValue, and a Property of type IGridCellEditControl called EditControl). It also defines a private Event Handler called OnEdit that is called and updates the displayed value whenever the OnEditComplete Event of the specific object that the EditControl Property refers to fires. This object could be expanded to include functionality like showing/hiding the discrete object EditControl refers to at appropriate times (show when the user clicks the cell, hide when OnEdit updates DisplayValue), determining whether the grid cell is presently editable (if the EditControl Property hasn’t yet been set, editing could be disabled), etc. The main point is, GridCell is able to do all this, without ever needing to know how the object that EditControl refers to actually works. This is where Interfaces add value to an object-oriented design.

---

To summarise, Implementation Inheritance tends to be most useful in situations where you have total control over all of the objects that will be used in conjunction with your design, and you are able to identify a subset of characteristics that are shared by several discrete objects you wish to model. Faced with this type of design problem, placing any less-specific shared characteristics in a base class (or longer inheritance chain), and inheriting accordingly allows you to reuse code, and separate concerns. Interface Inheritance, on the other hand, is useful in circumstances where you have a small number of discrete Properties, Methods and Events that you require to be implemented by a third-party object, the inner workings of which you don’t have influence over. Whenever a third party component developer requires that you implement an Interface within your object in order to use your class within their design, they’ll be setting that requirement for exactly the same reason in reverse: they’re saying that you’ll be able to take advantage of the benefits that their design facilitates, provided you implement a minimum subset of functionality that they’ve pre-defined in order to act as an interface between your (to them unknown) object and their design.