Code Crafter

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

Scala is a very feature-rich language built on top of the JVM (there's also a version on the CLR , but the focus is clearly on the JVM). Besides its functional features, it introduces a number of constructs that facilitate large scale components development and code reuse. Scala has traits, which are a great tool for orthogonal code reuse. In its simplest form, a trait can be used just like an interface, with only abstract members, defining a contract that derived types must fulfill. It can also have concrete members, including properties and fields. Classes (and traits) can inherit from multiple traits ("inherit" is the wrong term here, better ones are "use" or "mix in"), and gain all their capabilities. Traits enable a kind of composition that doesn't rely on the structure imposed by a multiple inheritance relationship. It's more suitable for combining a target class with the roles that it performs, which should not be part of its inhe...

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

Extension methods are an interesting feature of C#. They allow for behavior to be added to existing classes. For example, a ToXml() method can be added to class Object , effectively making that method available everywhere: public static class XmlSerializableExtension { public static string ToXml(this Object self) { if (self == null) throw new ArgumentNullException(); var serializer = new XmlSerializer(self.GetType()); using (var writer = new StringWriter()) { serializer.Serialize(writer, self); return writer.GetStringBuilder().ToString(); } } // for completeness... public static T FromXml<T>(string xml) { var serializer = new XmlSerializer(typeof(T)); return (T)serializer.Deserialize(new StringReader(xml)); } } So, any instance can be serialized to XML simply like this: var customer = new Customer { Name = "Guybrush Threepwood", Preferred = true }; var xml = customer.ToXml(); Now, certainly all classes ...