NRoles: An experiment with roles in C#

In the last months, I've been developing in my spare time a proof-of-concept post-compiler with Mono.Cecil to enable roles in C#: NRoles. Roles are high level constructs that enable better code reuse through easier composition. They are very similar to traits as described in the traits paper (pdf).

Set up

NRoles is hosted on google code. You can get the latest source code with this mercurial command:

  hg clone https://code.google.com/p/nroles/ nroles

You can also download the latest binary package from the downloads page.

To set up a Visual Studio project to use NRoles, unzip the binary package (or compile from source) in a folder accessible to the project. I normally have a project root folder, with folders for the project code (src) and for any used libraries (lib). For example:

  src\
    project files ...
  lib\
    nroles-v0.1.2-bin\
      NRoles.dll
      nutate.exe
      other NRoles binaries ...

In the project, add a reference to the NRoles.dll assembly. This is a very minimal assembly used to annotate the code to enable the post-compiler to create roles and compositions. Then, add a post-build event to the project to run the post-compiler (nutate.exe):

  "$(SolutionDir)..\lib\nroles-v0.1.2-bin\nutate.exe" "$(TargetPath)"

Now nutate.exe runs whenever the project is built, and any errors or warnings are reported in the Visual Studio error list view.

Roles and compositions

Let's take a look at some code based on the examples in the traits paper. Roles are classes marked with the interface NRoles.Role. This is a simple role that implements IEquatable<T> and provides a Differs method:

public abstract class REquatable<T> : IEquatable<T>, Role {
  public abstract bool Equals(T other);
  public bool Differs(T other) {
    return !Equals(other);
  }
}

To distinguish roles from normal classes or interfaces, I prefix them with the letter R. REquatable<T> provides the Differs method, but still requires classes that compose it to implement Equals, since it's abstract.

To compose a role, a class uses the NRoles.Does<TRole> marker interface, with the desired role as a type parameter. A role can also compose other roles. This is a role that implements IComparable<T> and composes REquatable<T>:

public abstract class RComparable<T> : IComparable<T>, Does<REquatable<T>>, Role {
  public bool Equals(T other) {
    return CompareTo(other) == 0;
  }
  public abstract int CompareTo(T other);
  public bool LessThan(T other) {
    return CompareTo(other) < 0;
  }
  public bool GreaterThan(T other) {
    return CompareTo(other) > 0;
  }
  public bool LessThanOrEqualTo(T other) {
    return CompareTo(other) <= 0;
  }
  public bool GreaterThanOrEqualTo(T other) {
    return CompareTo(other) >= 0;
  }
  public bool IsBetween(T min, T max) {
    return GreaterThan(min) && LessThan(max);
  }
}

Classes that compose RComparable<T> will also compose REquatable<T> and gain the implementations of the corresponding IComparable<T> and IEquatable<T> interfaces. RComparable<T> "implements" REquatable<T>.Equals in terms of CompareTo. CompareTo is left abstract and needs to be implemented by further composing classes.

RComparable

The following role represents a circle and composes REquatable<T> and RComparable<T>:

public class RCircle : Does<REquatable<RCircle>>, Does<RComparable<RCircle>>, Role {
  public int Radius { get; set; }
  public double Area { get { return Math.PI * Radius * Radius; } }
  public int CompareTo(RCircle other) {
    if (other == null) throw new ArgumentNullException("other");
    return Radius.CompareTo(other.Radius);
  }
}

All roles in a composition have the same priority. This includes all roles declared in the composition itself and also these roles' roles, and so on. Any role will only appear once in a composition, even if it was composed multiple times through different "paths". This way, it's very different from multiple inheritance, which requires you to consider the whole hierarchy and places different priorities in each class. As a result, conflicting members from multiple roles must be resolved by the composition (more on this here), which is also different from the way that mixin inheritance normally works, where the composition order defines the relative priorities of the mixins.

This simple composition represents the RGB (red, green and blue) values for a color:

public class Rgb : Does<REquatable<Rgb>> {
  public int R { get; set; }
  public int G { get; set; }
  public int B { get; set; }
  public bool Equals(Rgb other) {
    return R == other.R && G == other.G && B == other.B;
  }
}

And this role uses the Rgb composition and represents a color:

public class RColor : Does<REquatable<RColor>>, Role {
  public Rgb Rgb { get; set; }
  public bool Equals(RColor other) {
    return Rgb.Equals(other.Rgb);
  }
}

The next composition is a circle, and uses RCircle, RColor and REquatable<T>:

public class Circle : Does<RCircle>, Does<RColor>, Does<REquatable<Circle>> {
  public bool Equals(Circle other) {
    if (other == null) throw new ArgumentNullException("other");
    return
      this.As<RCircle>().Equals(other.As<RCircle>()) &&
      this.As<RColor>().Equals(other.As<RColor>());
  }
}

Circle has an Equals method that reuses the implementations from RCircle and RColor. Since NRoles works as a post-compiler, to use compositions in the same assembly that they're defined, the As<TRole>() extension method casts the composition type to one of its composed roles. This operation is always safe (provided that you post-compile the assembly). You don't need to use this trick in other assemblies, since the compositions are implicitly convertible to the roles that they compose. The roles become interfaces that the compositions implement (look here for the conceptual idea).

The Circle class ends up composing many behaviors from different roles, hopefully giving a taste of how roles improve the overall separation of concerns of the design.

Circle

NRoles is an experiment in a very early stage. Ideally, roles would be available in the language itself. But, I hope it can already be useful to create better designs; and maybe to show language designers that this is an important concept. So please, download and play with it, and comment on any issues and possibilities. And of course: contribute!

Comments

Post a Comment

Popular posts from this blog

The Acyclic Visitor Pattern

Knock knock The visitor design pattern is a way to add new operations to a hierarchy of classes without having to change the hierarchy itself. For example, with a simple hierarchy of fruits, you can have an IFruitVisitor interface that operates on the different classes in the hierarchy (in C#): interface IFruitVisitor { void Visit(Apple apple); void Visit(Grape grape); } The hierarchy classes then accept the visitor and fulfil the double-dispatching necessary to call the right Visit method: abstract class Fruit { public abstract void Accept(IFruitVisitor visitor); } class Apple : Fruit { public override void Accept(IFruitVisitor visitor) { visitor.Visit(this); } } class Grape : Fruit { public int NumberOfGrapes { get; set; } public override void Accept(IFruitVisitor visitor) { visitor.Visit(this); } } Note how each Accept method looks the same but is actually dispatching to a different method in the visitor ( Visit(Apple) and Visit(Grape) ). ...
Read more

C# Mixins With State

With the C# quasi-mixin pattern , one of the biggest limitations is that the mixins can't introduce state to a class. An alternative was for the mixin interface to require the composing classes to implement a property that the mixin would use as its own, as demonstrated in this example . In the .NET Framework 4.0, the ConditionalWeakTable<TKey, TValue> class can be used to associate arbitrary state to any instance. It's thread safe and it keeps a dictionary of weak references from the target instance to its associated state. If a target instance has no references outside the conditional weak table, then it can be reclaimed by the garbage collector. When that happens, its entry in the table is removed. This makes it possible for a mixin-like class to maintain state for the instances it extends. Let's look at a mixin for a message container: public enum MessageType { Error, Warning, Info } public class Message { public readonly MessageType Type;...
Read more

Some OO Design

"The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology." - Craig Larman I've recently found the following interview question on stackoverflow : Basic sales tax is applicable at a rate of 10% on all goods, except books, food, and medical products that are exempt. Import duty is an additional sales tax applicable on all imported goods at a rate of 5%, with no exemptions. When I purchase items I receive a receipt which lists the name of all the items and their price (including tax), finishing with the total cost of the items, and the total amounts of sales taxes paid. The rounding rules for sales tax are that for a tax rate of n%, a shelf price of p contains (np/100 rounded up to the nearest 0.05) amount of sales tax. This is a very familiar example that can be used as a really good gauge of various software development skills. There are many different ways to solve this problem. ...
Read more