Mixin Pattern (Class?) in C#

Mixin class is not a pattern because mixin is really not a pattern. It is, rather, a peculiar way in which class inheritance can be accomplished. The famous design patterns book defines mixin class in its opening chapter using these words:

A mixin class is a class that is intended to provide an optional interface or functionality to other classes. It’s similar to an abstract class in that it is not intended to be instantiated. Mixin classes require multiple inheritance.


This definition is basically correct, but it requires one additional note before putting it into the C# environment.

Mixin class requires multiple inheritance, plus it is abstract. In terms of C# as a programming language with single inheritance only, this means that mixin will in fact be the interface. Interfaces are abstract, and they can be inherited, that is, implemented even when the class already inherits from another class.

In C# we can create a mixin with a combination of an interface plus extension methods. LINQ is the canonical example of this with two core interfaces IEnumerable<T> and IQueriable<T> and a collection of extension methods on those interfaces.

It’s easy to create your own mixins.

For example, say I want to provide location functionality to various entities. I can define an interface like this:

public interface IPlay {  
  string File
     get; set; 

And then some extension methods for that interface:

static class PlayExtensions {    
    public static void PlayAudio(this IPlay play) { 
   public static void PlayVideo(this IPlay play) { 

Now, if we’ve got some entities like:

public class CameraPlayer: IPlay 
public string File { get; set; }

public class DVDPlayer : IPlay {
public string File { get; set; }

We can use the mixin like this:

var dvdPlayer = new DVDPlayer { File = “..?” } ;

Take Away is:

  • Extension method acts as any other method defined on the class. However, it can only see public members of the class.

Should we go with Delegate or Interface?

Delegate and Interface can provide you a a great mechanism that will separate the definition from the declaration.
Before we go into the detail about when to use what, let us first understand what is delegate (C/C++ pointers) and what is interface.

What is Delegate?

A delegate is a pointer variable declared as a variable of custom build type that can stores the reference to a function. The type should define method’s return type and its parameter types.

The following define a delegate type called StreamWriter

delegate bool StreamWriter (string text);

Here’s a complete example:

delegate void StreamWriter (string text);

class Test {
static void Main() {
StreamWriter t = ConsoleWriter;
t("Print this");

public void ConsoleWriter(string value) {

What is Interface?

An interface defines a template for its implementors. Just like an construction architect gives a blue print look through model, a software architect can use Interface as a tool for a blue print look for classes.

Should we go for Delegate or Interface?

  • Use a delegate in the following circumstances:
  • An eventing design pattern is used; that is multicast capability is needed.
  • It is desirable to encapsulate a static method.
  • The caller has no need to access other properties, methods, or interfaces on the object implementing the method i.e. The interface defines only a single method.
  • Easy composition is desired.
  • A class may need more than one implementation of the method; The subscriber needs to implement the interface multiple times.

Use an interface in the following circumstances:

  • A class only needs one implementation of the method.

In conclusion, it all comes down to your architecture. If your architecture needs event looks like callback operations. Then delegate wins over Interface. But if you want to define few methods along with some properties to be available through template then interface is your best choice.