Got your attention yet?  Well, truth be told, it doesn’t really have multiple inheritance; not in the true sense.  However, with a little creativity in technique, and provided your needs are not too deep, you can simulate a pseudo-multiple-inheritance scenario.  So let’s start by totally stating the obvious.

We have BaseClass1 and BaseClass2, each with methods that write out to the console a message identifying themselves.

public class BaseClass1
{
    public void BaseMethod1(string arg1, bool arg2)
    {
        Console.WriteLine(string.Format("BaseMethod1 in BaseClass1 called with arguments: {0} & {1}.", arg1, arg2.ToString()));
    }

    public void BaseMethod2(string arg1, string arg2)
    {
        Console.WriteLine(string.Format("BaseMethod2 in BaseCall1 called with arguments: {0} & {1}.", arg1, arg2));
    }
}

public class BaseClass2
{
    public void BaseMethod1(string arg1, bool arg2)
    {
        Console.WriteLine(string.Format("BaseMethod1 in BaseClass2 called with arguments: {0} & {1}.", arg1, arg2.ToString()));
    }

    public void BaseMethod2(string arg1, string arg2)
    {
        Console.WriteLine(string.Format("BaseMethod2 in BaseCall2 called with arguments: {0} & {1}.", arg1, arg2));
    }
}

Now we have a couple of other classes which have their own methods and each also inherits from one of the base classes.  We all know that .NET will limit the inheritance to only one class.

public class DerivedClass1 : BaseClass1
{
    public void DerivedMethod1()
    {
        Console.WriteLine("DerivedMethod1 in DerivedClass1 called.");
    }
}

public class DerivedClass2 : BaseClass2
{
    public void DerivedMethod1()
    {
        Console.WriteLine("DerivedMethod1 in DerivedClass2 called.");
    }
}

If I instantiate these two classes, I can call either their own methods or the ones declared in the base class, right? 

DerivedClass1 dc1 = new DerivedClass1();
dc1.BaseMethod1("hello", true);
dc1.BaseMethod2("hello", "world");
dc1.DerivedMethod1();

DerivedClass2 dc2 = new DerivedClass2();
dc2.BaseMethod1("hello", true);
dc2.BaseMethod2("hello", "world");
dc2.DerivedMethod1();

Have I insulted your intelligences enough by stating the obvious in about as boring fashion possible?  Well I did that for a reason.  See, my needs are to give the functionality provided  by both base classes to a derived class and still keep it apart in two separate entities; only my so-called entities won’t be classes this time, they’ll be extension methods.

Extension methods, introduced in .NET 3.5, allow me to add functionality in the for of methods to existing types.  This is a little like subclassing the type, but in a different way.  You can add extension methods to types that are sealed, and don’t accept subclassing.  You can also add them to classes that meet a certain contract or more specifically, implement a specific interface.  That’s the technique I’m gong to use now.

As you more than likely know, .NET types can only derive from a single type, but they can implement as many interfaces as you need.   So the firs thing I’m going to do is refactor my base classes so they are interfaces instead.  Yeah, I know, interfaces don’t offer implementation, just definition.  Don’t worry I’ll get to that.  What you’ll notice though is the simplicity of my two interfaces

public interface IBase1
{
}

public interface IBase1
{
}

By simplicity I mean, emptyness.  These interfaces are basically just marker interfaces and will contain no definitions for anything.   What they will do is offer an abstraction on which to define an extension, using extension methods.  Extension methods are defined as static methods first of all.  In fact, the way we code them is simply syntactic sugar for the actual static methods into which the language compiler will turn them.  The first argument of each static method will correspond to the type I want to “extend”, and is identified as such with the word this in front of it.

public static class Base1Extensions
{
    public static void Base1Method1(this IBase1 baseClass, string arg1, bool arg2)
    {
        Console.WriteLine(string.Format("BaseMethod1 from IBase1 called with arguments: {0} & {1}.", arg1, arg2.ToString()));
    }

    public static void Base1Method2(this IBase1 baseClass, string arg1, string arg2)
    {
        Console.WriteLine(string.Format("BaseMethod2 from IBase1 called with arguments: {0} & {1}.", arg1, arg2));
    }
}

public static class Base2Extensions
{
    public static void Base2Method1(this IBase2 baseClass, string arg1, bool arg2)
    {
        Console.WriteLine(string.Format("BaseMethod1 from IBase2 called with arguments: {0} & {1}.", arg1, arg2.ToString()));
    }

    public static void Base2Method2(this IBase2 baseClass, string arg1, string arg2)
    {
        Console.WriteLine(string.Format("BaseMethod2 from IBase2 called with arguments: {0} & {1}.", arg1, arg2));
    }
}

Notice that in these methods, the first argument is of the type of one of the two interfaces.  Extension methods don’t have to extend specific types, they can also extend classes that implement a certain interface or inherit from a certain base class.  In this case, the former.  Notice that the implementation for each of these four methods is identical to the implementations defined earlier in BaseClass1 and BaseClass2.  All four of these methods could have been placed into one static class, since the class does nothing more than provide housing for the methods.  But I chose to split them up to better mimic the original base-class scenario.

Now I can attach the functionality provided by these methods any class, simply by implementing the appropriate interface.

public class DerivedClass3 : IBase1, IBase2
{
    public void DerivedMethod1()
    {
        Console.WriteLine("DerivedMethod1 in DerivedClass3 called.");
    }
}

Now, DerivedClass3 can call any extension method designed to extend the IBase1 or IBase2 interfaces.

DerivedClass3 dc3 = new DerivedClass3();
dc3.Base1Method1("hello", true);
dc3.Base1Method2("hello", "world");
dc3.Base2Method1("hello", true);
dc3.Base2Method2("hello", "world");
dc3.DerivedMethod1();

This does have its limitations.  Unlike a true base-class scenario, the code in each extension method can only access members of the type it is extending.  And in this case, that type is an interface and an empty one at that.  So obviously, this technique is useful only when the implementation code you want is not going to need any outside dependencies, while methods in a true base class can depend on other members of that base class.  Another limitation is that extension methods can only be just that, methods.  This technique would not work if you’re looking to simulate property inheritance.

So there you have it, multiple inheritance in .NET – ok maybe not, but pretty cool huh?

Until next time…

We’re running the WCF Firestarter event in Philadelphia on September 18th.  This event was extremely successful in NYC, and give the great community that Philly has, I expect nothing less than an awesome turnout here as well.

The speakers will be myself, Danielo Diaz (DE), and Bill Wolf.

Here’s the registration link:  http://www.eventbrite.com/event/834424787/estwbreg

I just posted my latest pet-project in the downloads section of this site (look in the Free Code Projects folder).  This is an extensibility framework that I wrote to provide plumbing for some of my favorite extensibility patterns.  I recently recorded a DnrTv episode, showing it off, so I won’t go into it in great detail here.

I offer it to anyone who wants to check it out free-of-charge.  All I ask in return is that if you find it cool and/or useful, to let me know.  I’m currently working on the next version which adds a couple of more patterns and I have many more things planned for it, but none at the expense of its simplicity of usage.  The code download includes the framework and sample usage scenarios as shown on the show.  The version I posted also covers a provider model which was not done when I recorded the show.  I’ll have a full Help file soon so please bare with me.

This framework is not meant to be a workflow solution, as I explained on the show.  It’s also very different from MEF and provides different patterns.  I have nothing against MEF, but extensibility is something I’ve been doing for a long time and I have my own patterns and my own ways of doing things.  This is what the Pipeline Framework wraps.  Save your breath if all you are going to comment on is that I should be using MEF instead.  As I said, the patterns I use in this framework are very different.

I’ll post regular updates as I add new features.  In the mean time, I look forward to your comments and suggestions, positive or negative.

Callback functionality in WCF allows the service to call back to the client and send information or notification back.  In essence, reversing the client-service roles.  It’s a rather simple model with great benefits, specially if you want to keep the client notified on a long running process and display said notifications on the UI.  However, it’s not a trivial matter to deal with proper thread handling when using this functionality.  Most WCF callback demos will simply popup message boxes to show you when a callback has taken place, but if you need to do something more substantial that is UI-related, there’s a few other things you need to take into consideration.

In the second installment of “This Week In Code”, I’ll give you a demonstration of a typical callback demo that you may run into often.  Then I’ll change it to a more real-world scenario and introduce additional thread-handling details that you must undertake.

I’m not going to turn this posting into a WCF callback tutorial so I’m going to assume that you know how callbacks work and how to set them up.  Here’s some client code that calls a service:

private void btnSimpleCall_Click(object sender, EventArgs e)
{
    using (MyDuplexClient proxy = new MyDuplexClient(new InstanceContext(this)))
    {
        proxy.SimpleTest();
    }
}

As you can see, it’s called from a button’s Click event.  This will become important later.

And here’s the service operation that calls back to the client:

public bool SimpleTest()
{
    Console.WriteLine("Serviced called.  Performing callback.");
    IMyCallback callback = OperationContext.Current.GetCallbackChannel<IMyCallback>();
    if(callback != null)
    {
        callback.PerformCallback();
    }
    Console.WriteLine("Callback performed.");

    return true; 
}

The client that made the service call is a Windows Form and as I stated, it was a button that fired off the event.  The form itself is the implementor of the callback contract, which is why the InstanceContext instance wraps this.  Of course, the form needs the callback contract’s implementation because that’s what gets called when the service executes the callback operation.  Here’s that implementation now.

public void PerformCallback()
{
    MessageBox.Show("Callback from service on the client");
}

This simple example will work just fine because the callback is simply throwing up a message box.  This mean it’s not accessing the actual form’s UI so there will not be any threading issues.  Unfortunately, most examples you see on WCF callbacks do only this and as soon as the developer mimics this pattern but performs some UI update to the actual form, they run into problems.  Let me alter my code example and explain why.

Ok, so this next example is supposed to make a service call from the form’s button, then the service will perform a potentially long iteration and every so many items in the loop, it will call back to the client to report progress.  The client simply wants to use the value in the callback to update a progress bar o the form:

private void button1_Click(object sender, EventArgs e)
{
    int max = Convert.ToInt32(txtMax.Text);
    int step = Convert.ToInt16(txtStep.Text);

     progressBar1.Minimum = 0;
     progressBar1.Maximum = max;

     MyDuplexClient proxy = new MyDuplexClient(new InstanceContext(this));

     int[] numbers = proxy.GetNumbers(max, step);

     foreach (int number in numbers)
     {
        lstNumbers.Items.Add(number.ToString());
     }
}

public void ReportProgress(int progress)
{
    progressBar1.Value = progress;
}

So what do you think is going to happen here?  Well we have a potential catch-22 with this scenario.  By default the callback will me automatically be marshaled to the UI thread before it gets executed on the client.  If that happens, accessing the progress bar directly from the callback operation is perfectly fine, except that the UI thread is currently in the middle of a service call, since it was initiated in the button click, so we have a deadlock scenario there.

One thing I can do is decorate the form (as the implementor of callback contract) with the CallbackBehavior attribute and tell it to not use the form’s Synchronization Context:

[CallbackBehavior(UseSynchronizationContext = false)]
public partial class Form1 : Form, IMyCallback

This means that the callback will now be executed on a background thread and not the same thread as the one that made the service call initially (which is the default behavior).  But now I’ve introduced another problem.  The ReportProgress callback operation can no longer directly access the UI since it’s not on the UI thread, so I need to marshal up to the UI thread in order to access the progress bar.

The best way to do this is to use the form’s Synchronization Context; a feature introduced back in .NET 2.0 but still relatively unknown.  Rather than use the old “invoke” technique, I’m going to grab the form’s synchronization context as early as possible and store it in a class-wide variable.  It doesn’t get any earlier than the form’s constructor, so I’ll do it there:

public Form1()
{
    InitializeComponent();
    _SyncContext = SynchronizationContext.Current;
}
        
SynchronizationContext _SyncContext = null;

Now I have accessible to me at any time, a variable that represents the form’s thread execution context; and I can use this variable from any thread I want since it will always point back to the UI thread.

Next, I’ll modify the callback operation to use the _SyncContext object in order to fire code to the thread it represents, in this case the UI thread:

public void ReportProgress(int progress)
{
    SendOrPostCallback setText = delegate
    {
        progressBar1.Value = progress;
    };

     _SyncContext.Post(setText, null);
}

Well, that takes care of my marshaling task, but I’ve just introduced the old problem all over again.  Remember, the UI thread was in use by the button’s event which is not over yet.  It seems I’m going round and round with nowhere to go.  Well, I do have a way out of this.  The solution to the problem lies in the way I fired off the service operation.  If you recall, my goal was to fire off the operation, receive occasional callbacks, and then once the service call was complete, I want to display results to a list box.  What I need to do is not lock up the UI while I make the service call so I’m going to fire off the service call on another thread; but not just the service call, the update to the list box as well.  If I don’t do both, then the service call will fire on another thread and the list box will attempt to update right away.  So the button’s Click event will make the service call on a separate thread, after which, on that same thread it will update the list box with the service operation results.  But since that’s a UI operation, it needs to marshal that little bit up to the UI.  But never fear, I have my old friend, _SynchronizationContext at my disposal.

Here’s the new button Click event:

private void button1_Click(object sender, EventArgs e)
{
    int max = Convert.ToInt32(txtMax.Text);
    int step = Convert.ToInt16(txtStep.Text);

    progressBar1.Minimum = 0;
    progressBar1.Maximum = max;

    int[] numbers;

    MyDuplexClient proxy = new MyDuplexClient(new InstanceContext(this));

    Thread thread = new Thread(delegate()
    {
        numbers = proxy.GetNumbers(max, step);

        SendOrPostCallback addListItem = delegate
        {
            foreach (int number in numbers)
                lstNumbers.Items.Add(number.ToString());
        };

        _SyncContext.Post(addListItem, null);
    });

    thread.Start();
}

The only drawback with this technique is that as soon as the button is clicked, the user will have control of the UI returned.  This may or may not be a good thing.  As you can see, there’s a lot to be concerned about when you’re using WCF callback’s to update UI.  The solution that immediately comes to mind to control the UI fully, is to use an asynchronous delegate instead of a Thread object.  in fact, the Thread object is not a good idea anyway because it doesn’t use the thread pool and thread initiation carries a lot of weight.  If I change the code to use an asynchronous delegate, I can declare the IAsyncResult object that the invoking the delegate will return, at a class level.  Doing this, gives me access to the state of the asynchronous call anywhere on the form.  Then I can check for the IsCompleted property before allowing other UI activity to occur.

Here’s the re-work using an asynchronous delegate instead.  Notice that thanks to the Func delegate and its overloads, I didn’t need to create my own delegate for this.  Also notice that true to the async delegate pattern, I use a callback method (not to be confused with the service callback) that will get fired after the task of the delegate is completed.  And it is here where I’ll update my list box.  The async delegate callback method gets fired on the same background thread that the delegate did its work, so I still need to marshal up to the UI thread in order to update it.

private void button2_Click(object sender, EventArgs e)
{
    int max = Convert.ToInt32(txtMax.Text);
    int step = Convert.ToInt16(txtStep.Text);

    progressBar1.Minimum = 0;
    progressBar1.Maximum = max;

    MyDuplexClient proxy = new MyDuplexClient(new InstanceContext(this));

    Func<int, int, int[]> proxyCall = new Func<int, int, int[]>(proxy.GetNumbers);

    asyncProxy = proxyCall.BeginInvoke(max, step, ServiceCallComplete, proxyCall);
}

void ServiceCallComplete(IAsyncResult ar)
{
    Func<int, int, int[]> proxyCall = (Func<int, int, int[]>)ar.AsyncState;

    int[] numbers = proxyCall.EndInvoke(ar);

    SendOrPostCallback addListItem = delegate
    {               
        foreach (int number in numbers)
            lstNumbers.Items.Add(number.ToString());
    };

    _SyncContext.Send(addListItem, null);
}

Now from anywhere else in the form where a user action might take place, I can check the service call thread like this:

private void btnClear_Click(object sender, EventArgs e)
{
    if (_AsyncProxy.IsCompleted)
    {
        lstNumbers.Items.Clear();
        progressBar1.Value = 0;
    }
}

As you can see, using WCF callbacks, while easy, is not trivial when the work you want to do back at the client is UI related.  The first thing you should always ask yourself is, “do I really need to do this?”.  There’s a lot of details to take care of and even then, you may not get the effect that you would like.  In this last example, pressing the Clear button will simply do nothing.  In reality, you may want to disable controls on the form while the service call is taking place.  See, there’s quite a lot of worry about.

I hope you join me next week.  I have something really cool to show you; but I ain’t gonna tell you what it is.

Until next time…

In the tradition of Scott Hanselman’s “The Weekly Source Code”, I wanted to have a try at a weekly posting that’s all around code and coding techniques.  Most of these are probably going to come from stuff I come across in my coding endeavors, but I certainly will accept any contributions from readers.  As a warning, some may be short and some may long.  The idea is simply to share what I fee are cool coding approaches to problems or to share what I think may be not-so-good approaches to problem.  I do promise however, not to be critical about any code I don’t like without having an alternative of a better technique.  Also, expect a variety of length in this post-column.  They may range from single little code snippets to full-featured solutions and techniques.  In any case, they’ll all be filled with code.

So to kick off “This Week In Code”, I wanted to show you something that many of you may be familiar with since it’s really not new to .NET 4 (well not all of it anyway).  Be that as it may, I think it falls into the category of “still not too regularly used”.  The technique I’m going to show you has to do with Lambda expressions in my examples but can certainly be accomplished with anonymous delegates.

I’m not here to show you an intro to Lambda expressions, but instead how to mix them with the Action<T> and Func<T> delegates for some cool coding techniques.  But first, an introduction to these delegates:

The oldest and simplest is Action<T>.  This delegate was introduced back in .NET 2.0 and could be used with anonymous delegates.  The signature of this delegate is:

public delegate void Action<T>(T arg);

With this pretty free-form signature, the delegate is pretty useful in any scenario where you need to define methods with single signatures.  Later after my introduction, I’ll show you how to use this delegate in a cool technique.  Now, in .NET 4 Microsoft proved that their developers watch entirely too much Mythbusters, by falling into the creed of “What’s worth doing, is worth over-doing”.  I’m not being critical here; I fall into that one all the time myself.  In .NET 4, Microsoft expanded on the Action<T> idea and came out with Action<T1, T2>.  How’s that overdoing it you ask?  Well gentle reader, that’s not the overdoing part, this is: Action<T1, T2, T3>, Action<T1, T2, T3>, and Action<T1, T2, T3, T4>.  If you still think that’s not too much, it actually goes out to T8.

The signatures of these delegates are as you may guess, the same as the original but with additional arguments.  For example:

public delegate void Action<T1, T2, T3>(T1 arg1, T2 arg2, T3 arg3);

I guess you can call this a “one size fits all” delegate.

Also in .NET 4 came the introduction of the Func<TResult> delegate.  The signature of this delegate looks like this:

public delegate TResult Func<TResult>();

There’s also one that accepts a single argument called, Func<T, TResult>, whose signature looks as follows:

public delegate TResult Func<T, TResult>(T arg);

And as you can guess, there are others.  Specifically, Func<T1, T2, TResult> and so on all the way to T8 as well.

From what you can see here, the difference between the two delegates is that Action does not offer a return type and Fun does.  So what’s this good for?  Let me show you.

I’ll start with the Action delegate since its lack of return type make for a bit simpler example.  The Action delegate lets you assign a piece of code to a variable for later invocation.  The type(s) defined in the generic determine the types of the arguments you use in either an anonymous delegate or a lambda expression.  For my examples, I’m going to use lambda expressions and keep things current.  Check out this code sample:

Action<IProcessable> process = (processable =>
{
    processable.PerformSomethingHere();
    foreach (var item in processable.SubItemList)
    {
        item.DoSomethingWithItem();
    }
});

This code is designed to act upon any object that implements the IProcessable interface.  It simply calls a method defined by that interface then looks through a list property called SubItemList, which is also defined in the interface.  On each item in the list, it calls a method on that item.  This idea will be very similar to simply putting this code in its own method, then calling that method with any implementation of IProcessable.  However, if you have no need to use this code from multiple outside methods, yet still have to call it multiple times (as you’ll see in a second), defining it this way makes for great encapsulation and isolation.  So not let’s say I have an object hierarchy that looks something like this:

Parent.Children[x].GrandChildren

In other words, the Parent object has a collection of Child objects in a property called Children, and each child object has a collection of GrandChild objects in a property called GrandChildren.  The Parent, Child, and GrandChild classes all implement the IProcessable interface so I need to execute the code snippet you saw above on all these objects.  As I said, it’s easy enough to put the above-code in a method and just called that method from a for-each scenario on my Parent object, but I won’t need that code called from anywhere else and I want to keep all this encapsulated in my one method. I can use the processable variable and invoke it, sending into its argument any instance of the IProcessable interface.  The solutions is to do something like this:

Action<IProcessable> process = (processable =>
{
    processable.PerformSomethingHere();
    foreach (var item in processable.SubItemList)
    {
        item.DoSomethingWithItem();
    }
});

process.Invoke(Parent);

foreach(var child in Parent.Children)
{
    proces.Invoke(child);
    foreach (var grandChild in child.GrandChildren)
        process.Invoke(grandChild);
}

As you can see, the solution is simple and elegant and eliminates the need to have yet another method in your class.  If I wanted to pass in another value, like a boolean, into each invocation of the code snippet, I can use the Action<T1, T2> delegate.  the lambda expression would then have two variables in it.  Here’s the same code modified I the way I’ve just described:

Action<IProcessable, boolean> process = ((processable, b) =>
{
    processable.PerformSomethingHere();
    foreach (var item in processable.SubItemList)
    {
        item.DoSomethingWithItem();
        item.BooleanPropertu = b;
    }
});

process.Invoke(Parent, false);

foreach(var child in Parent.Children)
{
    proces.Invoke(child, true);
    foreach (var grandChild in child.GrandChildren)
        process.Invoke(grandChild, true);
}

It’s very important to wrap the two arguments prior to the lambda’s “goes to” operator using parentheses.  Pretty cool huh?  Yeah, I think so too .  Let’s take a look at using the Func delegate in a very similar fashion.  Remember, this delegate defines a return type as well.

The usage scenario for this delegate would be pretty much identical as the previous, only you would have the need to return a value from the invocation.  So this time, let me share with you a real-world example on where I’m currently using this delegate.  First let me set the scene.

I have a situation where I have to obtain three different database schema query filters (strings) from an incoming dictionary of key-value pairs (IDictionary<string, string>).  The dictionary comes into a method and potentially contains three items keyed by “TableFilter”, “CommandFilter” and “ViewFilter”.  I say potentially because the incoming dictionary may not contain all of these keys, or none at all, but those that are present contain values that are needed in individual variables.  So for example, under normal, boring code circumstances, I would need to check the incoming dictionary (a variable called arguments) to see if it contains the key TableFilter.  If it does, I set its value in a string variable called stringFilter.  I need to repeat this for the other two keys I’m looking for.  Oh, and did I mention that the arguments variable can come into my method as null as well?  And, if either the key is not found in the dictionary or the entire dictionary comes in as null, I still need my string variable(s) but with an empty string as their value.

Fine, you’re thinking I can simply check arguments for null first, then do a “contains” check on each key and then set each variable accordingly.  Man would that be boring!  Let’s do it in a much cooler way:

Func<string, string> filterCheckAndSet = (key => 
{
    string filter = "";
    if (arguments != null && arguments.ContainsKey(key))
        filter = arguments[key];

    return filter;
});

string tableFilter = filterCheckAndSet.Invoke("TableFilter");
string commandFilter = filterCheckAndSet.Invoke("CommandFilter");
string viewFilter = filterCheckAndSet.Invoke("ViewFilter");

Here, you can see I’m defining my code snippet in a Func<T, TResult> delegate type, where the first generic defines what I’m sending into the code and the second defines what I’m returning.  As you can see, I default my return-type to an empty string, I check the dictionary against it being null and also containing the key I need.  The key is one of the arguments I will send into the piece of code.  If I find the key, I set the my return variable to the contents of that dictionary item and then return it; yes I can do a return inside code defined in a Func delegate type.  Later, I simply invoke the filterCheckAndSet variable, sending in each key, and using the return value in each string variable I need.

That’s it.  I’ve found myself using these techniques more and more.  But remember, the biggest argument you’ll find against this is that you can accomplish the same with additional method calls.  My argument is, yes you can, but if you don’t need a specific level of code re-use, try to limit the scope of the code as it provides better encapsulation.  Also, remember that the code snippets are stored in object variables so they can be passed around anywhere you want (should you actually have that particular need).

For the next installment of “This Week In Code”, I want to address a pretty common threading issue when dealing with WCF callbacks, so stay tuned.

Until next time…