Before I get into my story, I will quickly explain what a mixin module is for clarity's sake.

A mixin is a way of expressing functionality that is not necessarily specific to a class, but can be mixed in to add the aforementioned functionality to a class. You might want to do this so that you can share behavior among different classes that do not share a class hierarchy. Sometimes you may want to use it as a purely organizational tool to keep related functionality for a class in the same place separated from the bulk of the implementation of a class. If you've ever had to slog through thousands of lines of code in a single class, most of which is unrelated to the functionality you're looking for, you can appreciate the value of separation for purely aesthetic reasons.

In ruby, a mixin module could look something like this:

module NameMethods def print_name puts name end end

This is a trivial example, but one aspect to note is that this module depends on the existence of a 'name' even though it is not defined within the module itself. There's no problem with this so long as it's included in a class which has a 'name'.

class Dog < Struct.new(:name) include NameMethods end my_dog = Dog.new('Pickles') my_dog.print_name # this prints 'Pickles' -- magical!

That's all very basic, and may be nothing new to you - but hey, if you've already learned something then prepare to have your mind blown! Or at least learn another nifty mixin trick.

The problem I ran in to yesterday was that I had a very large, complicated class that I wanted to add a mixin module to... but these mixins had overlapping method definitions, and as you might imagine the methods did very different things. The existing module had to work, but I still wanted to be able to use the new module within the context of the same class. HMM.

module LouderNameMethods def print_name puts "#{name} !!!" end end class BrokenDog < Struct.new(:name) include NameMethods include LouderNameMethods end broken_dog = BrokenDog.new('Sassypants') broken_dog.print_name # prints 'Sassypants !!!' # but now there's no way to get the original print_name behavior :(

The strategy I came up with was to define a new class which delegated method calls to an object that it wraps. In my very contrived example, it would clearly be easier to just change method names to avoid this conflict, but my real case was somewhat more complicated by the fact that it was non-trivial to change the implementation of the mixins since they were already used in several different cases, and each one of those would need to be changed and redeployed, which would increase the risk of breaking things that were already in good, working order. Anyway, I digress - my delegating class looked something like this:

class LouderDog < Struct.new(:wrapped) extend Forwardable include LouderNameMethods def_delegators :wrapped, :name end my_dog_only_louder = LouderDog.new(my_dog) my_dog_only_louder.print_name # prints 'Pickles !!!'

I chose to use Forwardable here, but you could also use Rails' delegate or if you are less picky about what you want to delegate to the wrapped class you can even use the standard library delegate stuff.

Now that you have a separate class with your colliding mixin it's up to you to determine which object instance to call print_name on. Your old code can continue to call the original mixin method with no changes, and your new code simply has to call the same method on a wrapped instance of the object. Good times!

The example I'm using here only dealt with method collisions, but the same technique can apply to mixins which might use and assign instance variables (@name for example). I wouldn't recommend using this technique frequently, but if you happen across mixins that collide (and are prohibitively difficult to change), now you know what to do!