C# Quasi-Mixins Example

As an example, I'll adapt one of the mixins found in the book Fundamentals of Object-Oriented Design in UML to use the C# quasi-mixins pattern.

Given the following (simplified) domain classes: 

namespace Domain {

  public enum Medium { 
    Email,
    SnailMail, 
    IntergalacticMail
  }

  public class Customer {
    public string Name { get; set; }
    public string Address { get; set; }
    public string Email { get; set; }
    public Medium PreferredMedium { get; set; }
  }

  public class Invoice {
    public string Header { get; set; }
    public List<string> LineItems { get; set; }
    public Customer Customer { get; set; }
  }

}

We'd like to be able to send an invoice to a customer by using his preferred medium. To keep the code to send the invoice separate from the Invoice domain class, and to abstract it so that it can send any kind of document (not just invoices) that adhere to a certain format, a mixin to send documents is created: 

namespace Mixins {

  public interface MSendableDocument {
    void CreateDocument();
    
    // data slot that the mixin needs
    [EditorBrowsable(EditorBrowsableState.Never)]
    object __DataSlot { get; set; } 
  }
  
  public static class SendableDocument {
    public static void ClearDocument(this MSendableDocument self) {
      self.SetDocumentBuilder(new StringBuilder());
    }
    public static void AppendTextToDocument(this MSendableDocument self, string text) {
      self.GetDocumentBuilder().AppendLine(text);
    }
    private static string GetDocument(this MSendableDocument self) {
      return self.GetDocumentBuilder().ToString();
    }
    private static StringBuilder GetDocumentBuilder(this MSendableDocument self) {
      return (StringBuilder)self.__DataSlot;
    }
    private static void SetDocumentBuilder(this MSendableDocument self, StringBuilder value) {
      self.__DataSlot = value;
    }
    public static void SnailMailDocument(this MSendableDocument self, string name, string address) {
      // example code....
      self.CreateDocument();
      string document = self.GetDocument();
      Console.WriteLine("Snail Mail\n  sent to {0}\n  at {1}", name, address);
      Console.WriteLine("Contents:");
      Console.WriteLine(document);
    }
    public static void EmailDocument(this MSendableDocument self, string name, string email) {
      // ...
    }
  }

}

Any class that represents a document that can be sent can use this mixin. The MSendableDocument mixin interface lists the required methods that it needs the target classes to implement. The extension methods to the mixin interface found in the SendableDocument static class provide the infrastructure needed for the target classes to assemble their document, realized through the methods ClearDocument and AppendTextToDocument. The target classes will provide the method CreateDocument, where a document will be assembled by calling the extension methods.

This mixin needs to keep state, it maintains the running document while the target class is building it. Unfortunately, the abstraction starts to break down, because extension methods are not suitable to maintaining per-instance state. (Update: Injecting state into a class can be done in the .NET Framework 4.0.) This issue is tackled by requiring the target classes to also implement a property, called __DataSlot, that the mixin will use to store any information it needs alongside the target instance's data. This is certainly not ideal. To accomodate future extensions of the mixin without breaking the target classes, the property is of type Object and its name is generic (data slot); to indicate that it's a kind of private property (even though it has to be public, because all the target class is doing is implementing an interface), it's preceded with double underscores and annotated with the EditorBrowsable attribute set to Never. If you ever use these kinds of mixins, it's very important that these conventions are communicated and understood by every developer in the team. This is particularly not suitable for API development, and should only be used in application development. A mixin without a data slot (i.e. it doesn't need to keep state) can be used in APIs though.

In the code, it's clear that the mixin uses the data slot to store a StringBuilder where it keeps the document that's being built. This is completely internal to the mixin implementation, and can be changed without disrupting the target classes.

All this code accomplishes something that would be much better expressed like this: 

// WARNING: invalid C# ahead
namespace Mixins {

  public mixin MSendableDocument {
    public abstract void CreateDocument();
    
    public void ClearDocument() {
      DocumentBuilder = new StringBuilder();
    }
    public void AppendTextToDocument(string text) {
      DocumentBuilder.AppendLine(text);
    }
    public void SnailMailDocument(string name, string address) {
      // ...
    }
    public void EmailDocument(string name, string email) {
      // ...
    }

    private StringBuilder DocumentBuilder { get; set; } 
    private string Document {
      get { return DocumentBuilder.ToString(); }
    }
  }

}

The SendableInvoice class uses the mixin: 

namespace Domain {

  using Mixins;

  public class SendableInvoice : Invoice, MSendableDocument {
    // NOTE: extension methods to "this" require the "this" variable!

    public void SendToCustomer() {
      switch (Customer.PreferredMedium) {
        case Medium.SnailMail:
        case Medium.IntergalacticMail: // not implemented, attempt Fedex!
          this.SnailMailDocument(Customer.Name, Customer.Address);
          break;
        case Medium.Email:
          this.EmailDocument(Customer.Name, Customer.Email);
          break;
      }
    }

    void MSendableDocument.CreateDocument() {
      this.ClearDocument();
      this.AppendTextToDocument(CreateHeaderText());
      this.AppendTextToDocument(CreateLineItemsText());
    }

    string CreateHeaderText() {
      return Header;
    }
    string CreateLineItemsText() {
      var sb = new StringBuilder();
      foreach (string lineItemText in LineItems) {
        sb.AppendLine(lineItemText);
      }
      return sb.ToString();
    }

    // needed by the mixin, not to be used by the class or its clients!
    object MSendableDocument.__DataSlot { get; set; }
  }
}

Invoices can now be sent like this: 

var invoice = new SendableInvoice {
  Customer = new Customer {
    Name = "Roger Wilco",
    Address = "Kerona Planet, in Orat's cave",
    PreferredMedium = Medium.IntergalacticMail,
  },
  Header = "Star Generator",
  LineItems = new List<string> {
    "The Generator ---- 1M bz",
    "Gift Card --------  1 bz",
    "Shipping --------- 1K bz",
    "Taxes ------------ 1K bz"
  }
};

invoice.SendToCustomer();

The advantage of this kind of mixin is that you can create decoupled functionality that can be reused in different contexts, in a way unattained by single inheritance. The disadvantage is that C# is not completely suitable for this task, and some workarounds are necessary, raising the need for strong conventions and effective communication.

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

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

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