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

Self-types in NRoles

Since roles are weaved into target classes, it's sometimes necessary for them to be able to identify the type of these classes. NRoles supports self-types through the use of a type parameter with the special name S : public abstract class REquatable<S> : IEquatable<S>, Role { public abstract bool Equals(S other); public bool Differs(S other) { return !Equals(other); } } To cast this to the type parameter, just use the Cast<T> extension method: public class Identity<S> : Role { public S Self { get { return this.Cast<S>(); } } } When other roles compose roles with self-types, they must flow the self-type through, since it will ultimately be determined by the target classes that compose them: public abstract class RComparable<S> : IComparable<S>, Does<REquatable<S>>, Role { ... } The post-compiler will check all classes that compose roles with self-types and issue an error message if the typ

Java 8 virtual extension methods are begging to be free of interfaces

To cope with API evolution and to provide new extensions for lambda-friendly methods, Java 8 will introduce a form of extension methods in interfaces (which were called public defender methods in previous iterations of the proposal). Interface methods will be allowed to have bodies (or just a reference to a static method): interface MyInterface { void method() default { System.out.println("A good idea?"); } } A class implementing MyInterface doesn't need to provide an implementation for method() . This is particularly valuable for interface evolution to maintain binary compatibility with classes already compiled with the old interface version. In general, the old binaries would work with the new defaulted interface method without recompilation; it will just use the default implementation. The default keyword is a deliberate choice not to conflict with the rule that "interfaces have no code". Now they can have default code. Conflict resolution

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.

Why is composition harder than inheritance?

(just some random thoughts...) Let's take this Java example: class Base { public void method() {} } class Derived extends Base {} See how easy it is for Derived to "reuse" code from Base ? Derived is a subclass of Base , and in its constructor it calls Base 's constructor, constructing a Base before constructing a Derived : class Derived extends Base { // this is what gets generated by the compiler: public Derived() { super(); } // this doesn't exist, but illustrates what happens when we call Derived.method: public void method() { super.method(); } } Also, Derived instances have a "forwarding" method, that, when called, will delegate to the corresponding base method (this is not technically what happens, but I'm looking at the "concept" here). Isn't that convenient? Why isn't the same capability available to compose classes? Composition is always a better strategy than inheritance in "reuse"

DCI Example with NRoles

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

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