Implementing Mixins with C# Extension Methods

Wikipedia defines a mixin as “a class that provides a certain functionality to be inherited by a subclass, but is not meant to stand alone. Inheriting from a mixin is not a form of specialization but is rather a means to collect functionality. A subclass may even choose to inherit most or all of its functionality by inheriting from one or more mixins through multiple inheritance. A mixin can also be viewed as an interface with implemented methods.”

Inheritance defines an “is a” relationship between classes. A car “is a” vehicle — a car is a specialization of a vehicle. A mixin, on the otherhand, is a means of sharing functionality among a series of related classes that do not inherit from the same base class. A mixin allows you to reuse code without implying a relationship among the classes. It also allows you to get around the Single Inheritance model a bit to do this.

An extension method is a new feature of C# 3.0. It is essentially a way of providing methods on existing classes that you may or may not have access to. This is similar in many ways to “open classes” that allow you to add methods to existing classes in languages such as Ruby. The interesting things is that you can add domain specific methods to framework classes like String or Int.

e.g.:
3.Days().FromNow()


public static class TimeMixin {
public static TimeSpan Days(this int days)
{
return new TimeSpan(days, 0, 0, 0);
}

public static DateTime FromNow(this TimeSpan timeSpan)
{
return DateTime.Now.Add(timeSpan);
}
}

This is a great way to keep code looking and feeling like Object Oriented code and avoiding a whole bunch of Utility classes with static methods. Avoiding these Utility methods keeps the power of OO for dealing with complexity through polymorphism and avoids the often more complex structures that come out of procedural code.

So, how do you use Extension Methods as Mixins?

Define an Interface (or use an existing one)

This could be anything from a marker interface to a full interface that defines a contract. In this simple example, I’ll make use of an existing interface.

public interface IComparable {
int CompareTo(object other);
}

Create Extension Methods for the Interface


namespace Mixins {
public static class ComparableExtension {
public static bool GreaterThan(this IComparable leftHand, object other) {
return leftHand.CompareTo(other) > 0;
}

public static bool LessThan(this IComparable leftHand, object other) {
return leftHand.CompareTo(other) < 0;
}
}
}

Notice the 'this' in the method declaration before the first parameter. The 'this' denotes an extension method. It defines the types of objects that will have this method available to be called on them.

Implement the interface in a Concrete class


namespace Domain {
public class Money : IComparable {
private double amount;
private string currency;
private CurrencyConverter converter;

public Money(CurrencyConverter converter, double amount, string currency) {
this.amount = amount;
this.currency = currency;
this.converter = converter;
}

public int CompareTo(object other) {
double otherAmount = converter.ConvertAmount(this.currency, (Money) other);
return this.amount.CompareTo(otherAmount);
}
}
}

Use the Code


namespace Domain {
using Mixin;

public class Account : IComparable {
private Money currentBalance;

public void Withdrawl(Money amount) {
if (currentBalance.LessThan(amount)) {
throw new BalanceExceededException(currentBalance);
}
// ... implement the rest of the method
}

public int CompareTo(object other) {
return currentBalance.CompareTo(((Account) other).currentBalance);
}
}
}

Now the LessThan and GreaterThan methods implementations are reusable on both the Money and the Account classes. They are of course available on any class that implements IComparable.

So now you can avoid some limitations of Single Inheritance and increase the amount of code reuse that is available to you with the concept of a Mixin. This is probably officially a 'sharp knife' so be careful with this kind of programming. It can be non-intuitive to people and can probably be greatly overused but it is a very valuable tool in many cases.

10 thoughts on “Implementing Mixins with C# Extension Methods”

  1. > So now you can avoid some limitations of Single Inheritance

    It is no secret that language limits both what we can think and express. When you can only think in terms of single inheritance, it deeply changes how you structure your object model. The reason is that when folks perform OOAD, they pretty much never look at the implementation language as a “runtime” on which to implement and deploy, instead they look at it as “how you can think”. Sure you can model a system with multiple inheritance, but you never do, because you know you will end up using a single inheritance language.

    > This is probably officially a ’sharp knife’ so be careful with this kind of programming. It can be non-intuitive
    > to people and can probably be greatly overused but it is a very valuable tool in many cases.

    You should try this out and go overboard. How else could you really get a good feel for how well it lets you grow the language into something powerful and useful? The mistakes made using this approach would be infinitely more valuable than the small-ish examples of its application.

  2. Great article!
    In fact this way of doing mixings through interfaces is a keystone in
    the impementacion of Linq and the Reactive Framework.

  3. in my example above – this post does not allow special chars so consider “YourClass” to be generic parameter

  4. Hi Geoff Lane,
    on your example,
    you never use “ComparableExtension” class on instant object. your example about mixin not yet clear.

    Agus Suhartono

  5. @Agus – that’s how extension methods work, you never explicitly “use” the class. It’s static, so you can’t instantiate it, and you don’t call the methods directly. Instead, the compiler knows to look through all static classes for extension methods when matching up method calls on an object.

    See the MSDN entry on Extension Methods.

  6. I think what Asus means is that you never use the GreaterThan or LessThan extension methods on an instance of the Account class.

    In this example use of a mixin would constitute the Account class exposing the interface of the Money class but delegating implementation of that interface to a composed instance of the Money class.

    This example does that by implementing the IComparable interface on the Account class and manually forwarding the IComparable implementation to the currentBalance instance of the Money class. What’s not clear is what’s the point of the extension methods in this example.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>