How to Implement Mixins in C#

Mixins and .net

I'm no expert, but this is what I found.

1. Mixins in C# 3.0
2. Implementing Mixins with C# Extension Methods

From MSDN Blog:

Mixins In C#

Some suggest that extension methods in
the upcoming C# 3.0 are a kind of
Mixins, because you can put in
functionalities in these methods and
arbitrarily tag it onto any class you
want. In the C# 2.0 specification
section 20.1.3 it is clearly called
out that the base class of a generic
class has to be a constructed class
type so this rules out using the above
approach to be used in C#. I am not
too sure on why we choose to
explicitly disallow abstract subclass.
Since C# does not support
multiple-inheritance, IMO it should
have supported Mixin style coding.

Is there anything Ruby Mixins can do what C# pseudo Mixins (Interface + Extension Methods) can't?

They are quite similar conceptually, but C#'s version is more conservative - Ruby Mixins get access to private instance variables, and can define private methods, or even replace methods. C# Extension Methods can only define public methods, and don't get any special access rights.

Ruby Mixins actually change the class, whereas Extension Methods are a method dispatch trick (the compiler says, "Any instance methods with name Foo()? Any Extension Methods? Yes? I'll just emit this as a call to this static method instead").

One other difference, is that Extension Methods are scoped, whereas Mixins are not (you cannot specify which Mixins you want in a Ruby file, once they're declared somewhere else, they're bolted on for life). Ruby has talked about adding this (they have some name for it, "specifications" or something?), but it ends up being quite complicated.

Moving singleton definition into mixins in C#

The mixins link you gave shows extension methods being used to add functionality to all objects supporting an interface. You still need to create the objects first. As singleton patterns handle the creation of objects it's basicly too soon to apply these techiniques.

Singleton needn't be so complicated, you're reading Jon Skeets article, a simple:

public sealed MyClass
{
   private MyClass(){}
   public static MyClass Instance = new MyClass();
}

Is often all you need. I'd happily repeat that code 10 times if needed. Or one can use a service locator or IoC container to manage the lifetime of objects.

Interface + Extension (mixin) vs Base Class

Downside of extension methods: clients pre-C#3/VB9 won't be able to use it as easily.

That's about it as far as I'm concerned - I think the interface-based approach is significantly nicer. You can then mock out your dependencies nicely, and everything is basically less tightly coupled. I'm not a huge fan of class inheritance unless it's really about specialization :)

EDIT: I've just thought of one other benefit which might be relevant. It's possible that some of the concrete implementations could provide more optimized versions of some of the general methods.

Enumerable.Count is a good example of this - it explicitly checks whether the sequence implements IList or not, because if it does it can call Count on the list instead of iterating through the whole sequence. If IEnumerable<T> had been an abstract class with a virtual Count() method, it could have been overridden in List<T> rather than there being a single implementation which knows about IList explicitly. I'm not saying this is always relevant, nor that IEnumerable<T> should have been an abstract class (definitely not!) - just pointing it out as a small possible disadvantage. That's where polymorphism really would be appropriate, by specializing existing behaviour (admittedly in a way which only affects performance instead of the result).

---

Related Topics