Nsryjdtyk

C# language (at least to version 5) does not have support for Traits.

However, Scala has Traits and Scala runs on the JVM (and CLR). Therefore, it's not a matter of run-time, but simply that of the language.

Consider that Traits, at least at the Scala sense, can be thought of as "pretty magic to compile in proxy methods" (they do not affect the MRO, which is different from Mixins in Ruby). In C# the way to get this behavior would be to use interfaces and "lots of manual proxy methods" (e.g. composition).

This tedious process could be done with a hypothetical processor (perhaps automatic code generation for a partial class via templates?), but that's not C#.

Happy coding.

I'd like to point to NRoles, an experiment with roles in C#, where roles are similar to traits.

NRoles uses a post-compiler to rewrite the IL and inject the methods into a class. This allows you to write code like that:

public class RSwitchable : Role

{

    private bool on = false;

    public void TurnOn() { on = true; }

    public void TurnOff() { on = false; }

    public bool IsOn { get { return on; } }

    public bool IsOff { get { return !on; } }

}



public class RTunable : Role

{

    public int Channel { get; private set; }

    public void Seek(int step) { Channel += step; }

}



public class Radio : Does<RSwitchable>, Does<RTunable> { }

where class Radio implements RSwitchable and RTunable. Behind the scenes, Does<R> is an interface with no members, so basically Radio compiles to an empty class. The post-compilation IL rewriting injects the methods of RSwitchable and RTunable into Radio, which can then be used as if it really derived from the two roles (from another assembly):

var radio = new Radio();

radio.TurnOn();

radio.Seek(42);

To use radio directly before rewriting happened (that is, in the same assembly as where the Radio type is declared), you have to resort to extensions methods As<R>():

radio.As<RSwitchable>().TurnOn();

radio.As<RTunable>().Seek(42);

since the compiler would not allow to call TurnOn or Seek directly on the Radio class.

There is an academic project, developed by Stefan Reichart from the Software Composition Group at the University of Bern (Switzerland), which provides a true implementation of traits to the C# language.

Have a look at the paper (PDF) on CSharpT for the full description of what he has done, based on the mono compiler.

Here is a sample of what can be written:

trait TCircle

{

    public int Radius { get; set; }

    public int Surface { get { ... } }

}



trait TColor { ... }



class MyCircle

{

    uses { TCircle; TColor }

}

This is really an suggested extension to Lucero's answer where all the storage was in the base class.

How about using dependency properties for this?

This would have the effect of making the client classes light weight at run time when you have many properties that are not always set by every descendant. This is because the values are stored in a static member.

using System.Windows;



public class Client : DependencyObject

{

    public string Name { get; set; }



    public Client(string name)

    {

        Name = name;

    }



    //add to descendant to use

    //public double Weight

    //{

    //    get { return (double)GetValue(WeightProperty); }

    //    set { SetValue(WeightProperty, value); }

    //}



    public static readonly DependencyProperty WeightProperty =

        DependencyProperty.Register("Weight", typeof(double), typeof(Client), new PropertyMetadata());





    //add to descendant to use

    //public double Height

    //{

    //    get { return (double)GetValue(HeightProperty); }

    //    set { SetValue(HeightProperty, value); }

    //}



    public static readonly DependencyProperty HeightProperty =

        DependencyProperty.Register("Height", typeof(double), typeof(Client), new PropertyMetadata());

}



public interface IWeight

{

    double Weight { get; set; }

}



public interface IHeight

{

    double Height { get; set; }

}



public class ClientA : Client, IWeight

{

    public double Weight

    {

        get { return (double)GetValue(WeightProperty); }

        set { SetValue(WeightProperty, value); }

    }



    public ClientA(string name, double weight)

        : base(name)

    {

        Weight = weight;

    }

}



public class ClientB : Client, IHeight

{

    public double Height

    {

        get { return (double)GetValue(HeightProperty); }

        set { SetValue(HeightProperty, value); }

    }



    public ClientB(string name, double height)

        : base(name)

    {

        Height = height;

    }

}



public class ClientC : Client, IHeight, IWeight

{

    public double Height

    {

        get { return (double)GetValue(HeightProperty); }

        set { SetValue(HeightProperty, value); }

    }



    public double Weight

    {

        get { return (double)GetValue(WeightProperty); }

        set { SetValue(WeightProperty, value); }

    }



    public ClientC(string name, double weight, double height)

        : base(name)

    {

        Weight = weight;

        Height = height;

    }



}



public static class ClientExt

{

    public static double HeightInches(this IHeight client)

    {

        return client.Height * 39.3700787;

    }



    public static double WeightPounds(this IWeight client)

    {

        return client.Weight * 2.20462262;

    }

}

Building on what Lucero suggested, I came up with this:

internal class Program

{

    private static void Main(string args)

    {

        var a = new ClientA("Adam", 68);

        var b = new ClientB("Bob", 1.75);

        var c = new ClientC("Cheryl", 54.4, 1.65);



        Console.WriteLine("{0} is {1:0.0} lbs.", a.Name, a.WeightPounds());

        Console.WriteLine("{0} is {1:0.0} inches tall.", b.Name, b.HeightInches());

        Console.WriteLine("{0} is {1:0.0} lbs and {2:0.0} inches.", c.Name, c.WeightPounds(), c.HeightInches());

        Console.ReadLine();

    }

}



public class Client

{

    public string Name { get; set; }



    public Client(string name)

    {

        Name = name;

    }

}



public interface IWeight

{

    double Weight { get; set; }

}



public interface IHeight

{

    double Height { get; set; }

}



public class ClientA : Client, IWeight

{

    public double Weight { get; set; }

    public ClientA(string name, double weight) : base(name)

    {

        Weight = weight;

    }

}



public class ClientB : Client, IHeight

{

    public double Height { get; set; }

    public ClientB(string name, double height) : base(name)

    {

        Height = height;

    }

}



public class ClientC : Client, IWeight, IHeight

{

    public double Weight { get; set; }

    public double Height { get; set; }

    public ClientC(string name, double weight, double height) : base(name)

    {

        Weight = weight;

        Height = height;

    }

}



public static class ClientExt

{

    public static double HeightInches(this IHeight client)

    {

        return client.Height * 39.3700787;

    }



    public static double WeightPounds(this IWeight client)

    {

        return client.Weight * 2.20462262;

    }

}

Output:

Adam is 149.9 lbs.

Bob is 68.9 inches tall.

Cheryl is 119.9 lbs and 65.0 inches.

It isn't quite as nice as I'd like, but it's not too bad either.

Traits can be implemented in C# 8 by using default interface methods. Java 8 introduced default interface methods for this reason too.

Using C# 8, you can write almost exactly what you proposed in the question. The traits are implemented by the IClientWeight, IClientHeight interfaces that provide a default implementation for their methods. In this case, they just return 0:

public interface IClientWeight

{

    int getWeight()=>0;

}



public interface IClientHeight

{

    int getHeight()=>0;

}



public class Client

{

    public String Name {get;set;}

}

ClientA and ClientB have the traits but don't implement them. ClientC implements only IClientHeight and returns a different number, in this case 16 :

class ClientA : Client, IClientWeight{}

class ClientB : Client, IClientHeight{}

class ClientC : Client, IClientWeight, IClientHeight

{

    public int getHeight()=>16;

}

When getHeight() is called in ClientB through the interface, the default implementation is called. getHeight() can only be called through the interface.

ClientC implements the IClientHeight interface so its own method is called. The method is available through the class itself.

public class C {

    public void M() {        

        //Accessed through the interface

        IClientHeight clientB=new ClientB();        

        clientB.getHeight();



        //Accessed directly or through the interface

        var clientC=new ClientC();        

        clientC.getHeight();

    }

}

This SharpLab.io example shows the code produced from this example

Many of the traits features described in the PHP overview on traits can be implemented easily with default interface methods. Traits (interfaces) can be combined. It's also possible to define abstract methods to force classes to implement certain requirements.

Let's say we want our traits to have sayHeight() and sayWeight() methods that return a string with the height or weight. They'd need some way to force exhibiting classes (term stolen from the PHP guide) to implement a method that returns the height and weight :

public interface IClientWeight

{

    abstract int getWeight();

    String sayWeight()=>getWeight().ToString();

}



public interface IClientHeight

{

    abstract int getHeight();

    String sayHeight()=>getHeight().ToString();

}



//Combines both traits

public interface IClientBoth:IClientHeight,IClientWeight{}

The clients now have to implement thet getHeight() or getWeight() method but don't need to know anything about the say methods.

This offers a cleaner way to decorate

SharpLab.io link for this sample.

This sounds like PHP's version of Aspect Oriented Programming. There are tools to help like PostSharp or MS Unity in some cases. If you want to roll-your-own, code-injection using C# Attributes is one approach, or as suggested extension methods for limited cases.

Really depends how complicated you want to get. If you are trying to build something complex I'd be looking at some of these tools to help.