Archive for the ‘mixins’ Category
Last time I presented a very high-level view of mixins: I called it the McFlurry Principle – take some base stuff, mix in something, get finished product. This time I want to go a little more into detail. As I’ve already said, mixins are all about code reuse. A mixin is basically a piece of code (or functionality), which is reused by merging it with an existing class. We call the class being merged the target type, the class that provides the code to be merged the mixin, and the resulting instance a mixed object.
There are actually three ways of mixing with re-motion. You can decide to merge a target class and a mixin when you write the target class (1), when you write the mixin (2), or when both are already given (3).
Let’s first discuss model number (1). Suppose you already have a class implementing a requirement, and you write a new class that wants to reuse that implementation. In ordinary OOP land, you now have two options: you can derive from the existing class, or you can create an instance of it and delegate to that instance. The former creates an is-a relationship, ie. your new class becomes a subtype of the existing class and can be put wherever the existing class is expected. This is convenient, but in the majority of cases, it is not what you want. Wise men have said before that you should favor object composition over class inheritance, ie. delegate to the existing code instead of inheriting it, and this is good advice, I think. (It only says favor, mind you, not always.) If you come into a situation where you want to inherit from more than one class, this is often a good hint that you’re overusing inheritance, so check your is-a relationships.
But in my programming language of choice (and that of my employer), object composition is not as easy to implement as inheritance. With inheritance, I simply write “: MyBase” somewhere at the beginning of my class declaration, and hurray, I have reused all of MyBase’s code! With composition and delegation, I usually have to type much more. This is why there is model number (1) in re-motion’s mixin implementation. It’s actually just a simple and wrist-friendly way of reusing a piece of code (the mixin) from a class (the target class) without forming an is-a relationship (and without using up your single base class). (This is also the main model behind by Ruby and Python mixins, if I’m not mistaken.)
In McFlurry speak, just to illustrate this using my favorite metaphor, model (1) is like creating vanilla, strawberry, and chocolate M&M McFlurries. How so? M&Ms are the existing component that you want to reuse, the different ice cream flavors are the different classes where you get to reuse them. (Of course, with food you don’t usually literally reuse. You buy more of the same.)
Model number (2). Consider the following case: You have a finished class model, and you run into a situation where you need exactly that class model, but adapted to a specific scenario. An example would be a general file management domain model (German link) which needs to be adapted to a specific client’s needs. You could of course derive from each of the classes in the given class model and add just the piece of code needed to extend it, but that will be cumbersome, and not wrist-friendly at all.
This scenario is the main reason why re-motion has a mixin implementation – we explained why exactly in the first (and funnier part) of the presentation we gave at Lang.NET 2008. It can be realized by implementing the extensions to the existing class model (target classes) separately as mixins, and configure the mixins to be applied to the class model as needed. One major benefit of using mixins for this is that if the modifications to the class model are very uniform, you only need to implement them once. You can then apply the same mixin to many target classes (or a base class, or even an interface!), as opposed to having to derive from every single class in your model.
To illustrate this model, consider having a supply of vanilla ice cream and needing to adapt it to specific client groups. So you mix in M&Ms for the children, Mars bars for people in need of energy (A Mars a day helps you work, rest and play; right?), and Bounty for the … fans of coconut. Or something. The thing being reused here is actually the vanilla ice cream (the target classes), the mixins modify the ice cream to form the product.
Model number (3) is similar to number (2), actually, but it has a different use case. Say you have a very generic implementation of a feature. For example, if an object is serializable, you can implement cloning by serializing it into memory and then deserializing it back, effectively creating a deep copy. (This is of course not the most efficient way to implement deep cloning in .NET, but it’s such a simple and straight-forward mechanism that it comes up quite often in discussions. And there’s always some smartass to point out its deficiencies 🙂 )
So you implement that feature as a generic mixin. And then, whenever you have a class that you need to be cloneable, you can simply merge it with the mixin to reuse the implementation. Astute readers might now ask why I’m not simply calling the existing implementation instead of creating a mixed object. One of the features of re-motion mixins is that a mixin can automatically add an interface to a target class. In our example, the mixin can choose to add the ICloneable interface to its target classes, so by using it, I again have a wrist-friendly way of adding both the functionality and the interface to my mixed object (where I normally would have to derive or wrap and delegate).
The metaphor here is easy. Just imagine a supply of different ice cream flavors and different candy stuff, and mixing them just as you want. Wow.
Next time: What mixins can, actually, do. And after that: A Code Sample. Or maybe two.
Edit: Fixed “full mix” link.
Edit 2: I was told it might make a bad impression to call somebody a smartass. Especially since not everybody might get whom I’m dissing there. If you feel uncomfortable with my attitude, rest assured that I’m insulting the only person who definitely doesn’t care. We’re on very good terms.
So, what is that re-motion mixins library, actually? In one sentence: it’s a library providing a mixin mechanism for static programming languages on the .NET platform.
This is probably not enough for making people ask me for autographs when they meet me on the street. So, let’s try to go into more detail. Let me take the main part of that statement and explain it: the library provides a mixin mechanism.
Mixins are a device for code reuse known mostly from dynamic programming languages such as Python, Ruby, or Perl. C++ templates can also be used to create mixins. While the specific implementations and feature sets vary from language to language, all mixin implementations have one thing in common: they aggregate code from different sources into single objects.
As Wikipedia tells me, the term “mixin” stems from ice cream, actually. Apparently, the creators of “Flavors”, a LISP implementation of object-oriented programming, took the name from Steve’s Ice Cream Parlor in Somerville, Massachusetts. Steve’s Ice Cream Parlor sold ice cream that was created in an interesting way: you took some basic flavor, mixed in some extra flavors, and got a delicious product.
In case this is too abstract, let’s simply call it the McFlurry Principle. (Calling it the “Steve’s Ice Cream Parlor in Somerville, Massachusetts Principle” would be more appropriate, actually, but that just doesn’t seem to have the same flow. McFlurry, by the way, is a trademark owned by the McDonald’s Corporation, to which I have no affiliation whatsoever. I don’t think I’ve ever even eaten a McFlurry, I have no idea what it tastes like, and I’m told the competitors have similar products.)
The McFlurry principle: take some base flavor, mix in extra flavors, get delicious product.
What does this have to do with software development? Well, mixins in software development also follow the same idea: you take some basic code model, you mix in additional stuff, you get a fully-featured product. That’s the idea behind mixins.
Up next: Mixins the re-motion way. Soon.