What do you think of this code?

I recently finished 6 weeks of coding for a client, and it was heaven! I actually got a chance to code every day, for 6 solid weeks. It was a chance for me to learn C# 3.0, and a chance to work on testing things that are hard to test. It was great!

Out of the work, came several interesting observations and coding techniques, all rooted in C# 3.0. Since no one at work has any experience with these new idioms I “invented”, “discovered”, or just “copied”, I’d love to get some reader feedback. I’ll start with this one trick I tried, and follow on with more as the mood strikes me over time.

Trick 1: Using extension methods and a marker interface in place of implementation inheritance

I had an instance of code duplication in two parallel hierarchies of classes, and I wanted to find a way to share the code. One option would be to use inheritance, factoring out another base class above BaseResponse and BaseRequest. This is where methods common to requests and responses could both live. Using inheritance as a way to reuse code in a single inheritance language is a pretty heavyweight thing to do. I’d rather find a way to use delegation, since that preserves the SRP in my class hierarchy. Instead, I decided to try an extension method, and just use that method where I needed it. To avoid polluting Object with unnecessary methods, however, I came up with the idea of using a marker interface on the classes I wanted to have these extension methods, limiting the scope where these extra methods were visible. (No idea if anyone else has done this yet or not)

ClassDiagram1

For each request and response class, in the two parallel  hierarchies, my client requirements made it necessary to add an XmlRoot attribute to tell the XmlSerializer that this object was the root of an XML document and to specify the runtime name of this element. To let me get the runtime name of each request and response object, for auditing and logging purposes, both hierarchies had a CommandName property, containing the exact same code. This was the code in question that I was trying to share.

As a simple exercise, I created an extension method to deal with this:

    internal static class SssMessageExtensionMethods
    {
        public static string GetCommandNameFromXmlRootAttribute(this object message)
        {
            object[] attributes = message.GetType().GetCustomAttributes(typeof(XmlRootAttribute), true);
            if (attributes.Length == 0) return message.GetType().Name;

            XmlRootAttribute xmlRootAttribute = attributes[0] as XmlRootAttribute;

            return xmlRootAttribute.ElementName;
        }
    }

This solution worked just fine, and the code ran correctly, but I still wasn’t happy with my solution. The problem I was sensing was that I was adding yet another extension method to Object, and Object’s neighborhood was already pretty crowded with all the Linq methods in there. I wanted my extension methods to show up only on those classes to which I wanted to apply them.

The solution that I came up with was to use a marker interface whose sole purpose is to limit the visibility of the extension methods to classes that I intend to apply them to. In this case, I made BaseRequest and BaseResponse each implement IMessageMarker, an interface with no methods. And I changed the extension method to be:

    internal static class SssMessageExtensionMethods
    {
        public static string GetCommandNameFromXmlRootAttribute(this ISssMessageMarker message)
        {
            object[] attributes = message.GetType().GetCustomAttributes(typeof(XmlRootAttribute), true);
            if (attributes.Length == 0) return message.GetType().Name;

            XmlRootAttribute xmlRootAttribute = attributes[0] as XmlRootAttribute;

            return xmlRootAttribute.ElementName;
        }
    }

Now I have the same extension method defined, but it only appears on those classes that implement the marker.

What do you think of this technique? In a more powerful language, like Ruby or C++ (ducking and running for cover!), this kind of trickery wouldn’t be needed. But C# can only get you so far, so I felt this was a good tradeoff between adding the methods for needed functionality and making the most minimal change in my classes to hide these methods so that only those places that needed them could see them.

— bab

16 thoughts to “What do you think of this code?”

  1. "a more powerful language, like Ruby or C++" <– You’re not comparing apples to apples here…

    Anyways, you should always apply stuff like this, imo, to just classes that can actually make use of it. It really doesn’t make sense to add it to "object", that’s just silly imo.

    Having said that; these kinds of scenarios are common and not easy to solve.

  2. You don’t really think extension methods were added to the compiler for any other reason than that LINQ needs them?

    I’d rather use static helper methods there, which is semantically much clearer. An extension method looks like a member, but it isn’t. Shame MSFT added that.

  3. This certainly introduces some interesting possibilities and potential side effects.

    An example I thought of is if the interface you use has a method with the same name as the extension method you can effectively override the concrete classes behavior… and achieve a new sort of method reuse aka multiple inheritance.

    Consider the following source code… some interesting "method shadowing" features exposed.

    class Program {

    static void Main(string[] args) {

    SomeExtensible a = new SomeExtensible();

    a.DoExt1();

    IExtensible b = new SomeExtensible();

    b.DoExt1();

    }

    }

    interface IExtensible {

    bool DoExt1();

    }

    class SomeExtensible: IExtensible {

    bool IExtensible.DoExt1() {

    throw new NotImplementedException();

    }

    }

    static class Extender {

    public static bool DoExt1(this IExtensible x) {

    return true;

    }

    }

    I’ll certainly be using this "feature".

  4. Why didn’t you just introduce a new class as a state property to the original class… using composition instead of inheritance.

    Class A

    {

    private SharedBehavior sharedBehavior;

    }

    Class B

    {

    private SharedBehavior sharedBehavior;

    }

  5. Hi, James,

    I didn’t want to do as you suggested, because I wanted to add public functionality to each class. If I had added a state property to the original class (actually there were 2 original classes), I still would have had to have created a delegating method to expose the feature I wanted.

    By using a marker interface and extension methods, I was able to model a mixin in a language with single inheritance.

    bab

  6. "a more powerful language, like Ruby or C++" <– You’re not comparing apples to apples here…

    Anyways, you should always apply stuff like this, imo, to just classes that can actually make use of it. It really doesn’t make sense to add it to "object", that’s just silly imo.

    <a href=http://www.ihackr.com>ihackr</a&gt;

  7. "Where the use of forces of <a href="http://www.inwowgold.com/">wow gold</a> the law, the wow gold whole country, breaking the country second; the army for <a href="http://www.inwowgold.com/power-leveling/">wow power leveling</a> the last, wow power leveling breaking Jun times;

    The brigade is on; <a href="http://www.sopgame.com/">wow gold</a> breaking wow gold tour followed; full soldier is on the broken soldier followed; full Ng is on the break <a href="http://www.sopgame.com/power-leveling/">wow power leveling</a> followed wow power leveling by Wu. "

    09.11.13T

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.