Code Crafter

The DCI (Data, Context, Interactions) architecture is a style that proposes an interesting separation of concerns between the domain model of a system (what the system is ) and its behavior (what the system does ), normally associated with its use cases. The rationale is that, since these parts incur change at different rates, isolating them from each other results in a system that's easier to understand, evolve and maintain. In order to enact a specific use case, a specialized context instantiates the necessary data objects assigned to the needed roles to run the required "algorithm". A very common example is that of a bank transfer operation. This example has already been described in C# with the C# quasi-mixins pattern . With NRoles the code for a role lives in a single abstraction, which results in a more compelling implementation. I'll change the example a little bit, to introduce a stateful role; something that's harder to achieve with pure C#. The...

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 ...

After seeing what roles in C# might look like, let's see the necessary transformations that would enable them. This is one possibility that a C# compiler could use to implement roles without having to make changes to the underlying CLR. Roles A role is transformed into a set of types: an interface (which the compositions will implement), a static class with the role code, and a class that encapsulates the role state. The interface for the role is the most important type and it will carry the role name. Because all the generated types are related, they'll be packaged together as nested types inside the role interface. Nesting types inside an interface is not supported in C#, but is supported by the underlying CIL. So we'll be looking at some invalid C# along the way; just think of it as "decompiled" CIL. Let's see these transformations for a simple role: role RPrintableWithCount { int count = 0; public void Print() { Console.WriteLine(...

Traits (pdf) are described as composable units of behavior, and are a natural evolutionary path for languages like C# or Java. Microsoft must be seriously looking at them, since it's sponsored some research about Traits in C# (pdf) . I'll describe what I think is an extension to the traits idea that would make a great feature in C# (and in Java, VB.NET, ...): roles. Roles are already a reality in Perl 5, with the Moose::Roles module. They even have their own syntax in Perl 6 . They help create better organized and reusable code, are an effective and safer alternative to multiple inheritance, and have explicit semantics (which means no surprises) as opposed to mixins. What I'll describe here is based on the theoretical traits (as described in the traits paper), on Perl roles and on Scala traits , all adapted to C#. A role is, like a class, a type that holds behavior and state. It can be composed into a type (either a class, a struct or another role) to make its memb...